Boston DevDays kicked off a month-long tour of technical talks aimed at programmers, organized by StackOverflow and Carsonified. I had the good fortune to attend, meet a few interesting people and see some fun talks. I tried to write a bit in real-time (search Twitter here) but the WiFi was pretty over-subscribed and there was no cell coverage to speak of so eventually I gave up. Here are some more detailed notes, starting with the morning sessions.
The day ran very much on schedule, and after some very loud music, DevDays opened with a funny video demonstrating the competent technical leadership of the keynote speaker…
Joel opened the day by giving a demonstration of the tyranny of computers: you are constantly interrupted with questions asking for decisions, like “Do you want to install these 10 updates to Windows?” or “Enable caret browsing?”, that can be really hard to answer. He argued that one of the reasons that computers ask us so many questions is that programmers want to give users the power (and control) to do what they want. But that’s another way of saying that programmers don’t want to make the decisions to keep things simple. The rest of Joel’s somewhat meandering but always entertaining talk was a discussion of how programmers (us!) should approach decision making, framed as a trade-off between simplicity and power.
Decisions are ultimately hard to make—there have been many studies that demonstrate that when people have too many choices, they freeze up and choose nothing. Thus, we’ve seen strong push towards simplicity in recent years; one clear example of that has been the Getting Real book from 37signals. Joel (jokingly?) points out that three of the four 37signals apps are in fact just one big textarea tag that you type into. Other examples, given later, include of course Apple’s products and Google.
But why do we wind up with programs with lots of options? Well, if you have a simple program, you find that most people won’t buy your product if it doesn’t have feature X (or Y or Z or …). So you wind up adding features over time, as you get more customers and more experience. Thus, removing simplicity often happens as a side-effect of making money.
How to balance these? If we don’t want to take away all decisions from the user, we need a rule to guide us in what to remove and what to keep. One rule to follow is that the computer does not get to set the agenda. Good decision points are those that should help the user achieve what they want to do. Bad decision points are those that interrupt the user, that the user really isn’t equipped to answer (e.g., should GMail automatically display inline images in HTML?), that are things that the programmer cares about.
To decide what is good or bad, developers need a good model to understand what the user is trying to do—Joel says every user is ultimately trying to replicate their DNA, but you may have some more refined model. Joel gave the example of Amazon’s 1-Click purchasing where the user should just be able to buy something with a single click. Apparently, early drafts of 1-Click really weren’t one click: programmers kept wanting to put in things like confirmation pages. Eventually, they arrived at just one click—by not immediately starting the order processing, but holding it for a few minutes to consolidate related 1-Click orders and allow for cancellation of errors. This was more work for the developers, but simpler for the user. This is what we want to see happen.
Overall, I think Joel’s talk set a nice tone for how we should think as developers but didn’t offer anything particularly ground-breaking.
Ned Batchelder on Python
Ned Batchelder presented Python as a “Clean noise free environment to type your ideas.” Or, alternatively, “Python is awesome.” With a few bullets to lead-off (e.g., the REPL, duck typing, and “batteries included” nature of Python), we dove into code to really understand what Python is capable of doing. Ned’s slides are online if you want to take a look. I won’t cover his talk in much detail since it was largely explaining the Python language but will list some high points.
The first example was Peter Norvig’s concise spell corrector.
This code makes ample use of list comprehensions and sets, plus functions like
collections.defaultdict, and parameterized
max, which were all new to me.
The second example was a custom build-up of a simple Python
templating engine, loosely based on Django’s template styles.
This example demonstrated simple formatting with the percent operator, but then quickly moved into more advanced features
like duck-typing (by implementing
One of the nice things about Ned’s presentation is that he demonstrated the power of Python in two short but extremely powerful examples that left people who didn’t know Python thinking, “Wow! That is really amazing!”
Dan Pilone’s talk was an overview of iPhone development, first giving a quick market overview, then giving a broad overview of the nitty-gritty of developing in Objective C, and finally diving into the practical economics and realities of selling iPhone apps. The iPhone app market (as of Apple’s September numbers), consists of something like 85,000 applications, of which 75% are pay applications. Some 35% of applications are games, whereas 6% fall into more social applications. There are 5 or 6 different iPhone/iTouch hardware platforms, and something like 20 million plus devices sold. The iPhone has a great user experience and comes with a great delivery model (the iTunes app store). This combined with some of the numbers make it a good platform to develop for, with significant amounts of money that can be earned. (Dan emphasized that you really have to work to develop and market the application, hence the “earned”.)
The iPhone development environment is very shiny. I’m sure Ars Technica has a much better overview but in short Dan demonstrated some tools like XCode, CoreData (a graphical SQLite data modeler), reference counting support (aka retain), and Instruments (a memory profiler). Dan suggested that this shininess is to make up for some of the oddities of Objective C that you’ll have to live with. He also demonstrated some of the interface builder tools and how they link up.
Testing turns out to be quite interesting; the simulator is okay but limited and often your app will work in the simulator but fail on real devices. For example, your app on a real device might “run so slow you wish it had crashed”. The simulator also doesn’t enforce sandboxing as strictly as real devices, where each app has its own uid and single directory where it can store data. There are also many different hardware variants that you have to support that limit you in different ways: for example, early iPhones only give you 40MB of memory to play with whereas newer ones give you almost 120MB. This is not reflected well in the simulator either.
Shipping an iPhone app on the app store requires approval, a process that can take two weeks per round-trip. There’s no way to get around it so you must budget in time for that in development. The approval store helps guarantee a minimal level of quality of apps—they will verify that your app indeed works on all different hardware, and they will (eventually) catch any licensing violations but they’re overall pretty reasonable.
Once you get approval, you show up in the recent releases section of the app store, and there you have about 24 hours to get popular or else you will fade into the long tail of oblivion. In fact, if you are in the top 50 apps, you will easily get double the sales (presumably relative to the 51st app); if you are in the top 10, you’ll be getting an order-of-magnitude more sales. So, make sure you get your approval/release-date lined up with your marketing blitz. The alternative is to charge a bit more than $0.99, and go for slow but steady sales.
As a Blackberry owner and Linux user, I found Dan’s talk to be a great introduction to iPhone development. Presumably his new ORA book, Head First iPhone Development, would be a good buy if you are in to that sort of thing.
Joel on FogBugz
Before lunch, Joel took the opportunity to give a pitch for his company’s FogBugz product,
and announce some new features. He gave us a walk-through of its capabilities, from
organizing documentation, to project planning, to bug tracking, to user support. New features announced
are a rich plugin architecture, plus support for Mercurial and code reviews
in a new hosted plug-in to FogBugz called Kiln. He spent a fair amount of time
on that, demonstrating calling
hg push from the command line. He also demonstrated the evidence-based scheduling features of FogBugz.
Nothing too exciting for me working in a big company using Perforce, but a good marketing opportunity for FogCreek and a nice chance to see how some other people do scheduling and bug tracking. I was a bit disappointed that there’s no direct way to do pre-commit (i.e. pre-push) reviews a la Gerrit, but @jasonrr says you can set up a branch repo, push to that and then review there before merging to main. I expect this means that GitHub will be getting code review support soon.