In this case, DC = Falls Church, VA. I went to the State Theatre to attend this conference. Considering the cost ($99/person), the conference turned out to be a great value. I wrote up a conference report to share with my bosses and co-workers and it’s included below. It has footnotes because I typed it up in Word 2007 and pasted it in here with very little editing (because after all this writing, I’m feeling a bit lazy).
Summary
The main reasons the creators of stackoverflow.com came up with this conference include the following:
- Bring together developers that are part of the Stack Overflow community[1]
- Teach developers something outside their immediate field[2]
- Accomplish 1 & 2 at low cost[3]
A fourth reason I would add is to pitch FogBugz 7. It’s the primary product offering of Fogcreek Software, so it would have been odd for a conference it supports to not do at least a little advertising. Spolsky also attempted to divide the venue by area for networking around certain topics, but I’m not sure how successful that was.
The conference succeeded in its main objectives. At $99 per person, this conference was a bargain. Given the diversity of topics and caliber of speakers, the price could have been higher and the venue would still have sold out. Of the seven official topics presented (there was an eighth on Agile after the conference ended), only the ASP.NET MVC talk used technology that I had hands-on production experience with. I was disappointed not to see a presentation on Android, but that was the only thing obviously missing from the day.
Keynote: Joel Spolsky
If I were to boil down Joel Spolsky’s keynote to a single phrase, it would be this:
“Death to the dialog box!”
Spolsky’s talk argued persuasively that software often forces users to make decisions about things they don’t care about, or don’t know enough about to answer correctly. Among his examples were modal dialog boxes for products like QuickBooks and Internet Explorer, and the Windows Vista Start button. He talked about the other extreme (overly simple applications) as well, using the “build less” design philosophy of the 37signals team as an example.[4] Equating those kinds of applications with Notepad was a reach (and clearly played for laughs), but described the limitations of the alternative to complex applications pretty well. The examples did a good job of setting up the choice between simplicity and power.
He cited an experiment in the selection of jam from The Paradox of Choice: Why More Is Less[5] to show the potential drawbacks of too many choices. When the results of this experiment showed that a display with fewer choices resulted in an order of magnitude more sales of jam, it put a monetary value on the design decision to limit choices.
Predictably, his examples of the right kind of design were products from Apple. It takes a lot more effort to put a Nokia E71 in vibrate mode than it does an iPhone. Spolsky pointed to the iPod’s lack of buttons for Stop and Power as examples of addition by subtraction. The best example he chose was actually Amazon’s 1-Click shipping. In addition to offering the most reasoned defense I’ve heard yet of Amazon winning that patent, he explained how it works for multiple purchases.
A few other takeaways from the Spolsky’s keynote that I’ve tried to capture as close to verbatim as possible are:
- The computer shouldn’t set the agenda.
- Bad features interrupt users.
- Don’t give users choices they don’t care about.
iPhone Development: Dan Pilone
This talk successfully combined technical depth on iPhone development with information about business models for actually selling an app once it’s complete. Pilone discussed which design patterns to use (MVC, DataSource, Delegate) as well as what paid applications are selling for in the App Store (the highest-grossing ones sell for between $4.99 and $9.99).
One of the most useful parts of the talk was about the approval process. He gave his own experience of getting applications through the submission process, including one that was rejected and the reasons why. According to him, 2 weeks is average time it takes Apple to accept or reject an application. It’s even possible for upgrades of a previously-accepted app to be rejected.
Pilone did a good job of making it clear that quality is what sells applications. He used the Convert[6] application (from taptaptap) as an example. It’s just one of over 80 unit converter applications in the App Store, but it’s beating the competition handily. OmniFocus was his second example.
Revenue Models
- Ad-supported (very difficult to make money with these)
- Paid
- In-app upgrades[7]
Dan Pilone is the co-author of Head First iPhone Development[8], which will be available for sale on October 29.
His recommendation for selling apps in the App Store is to release a paid version first, then an ad-supported version. This advice seemed counterintuitive to me, but I suspect he suggested it because there’s no data on the in-app upgrades revenue model. I see in-app upgrades as Apple’s most explicit support for the “freemium”[9] business model yet.
ASP.NET MVC: Scott Allen
This talk was basically a demo of a preview version of ASP.NET MVC 2. Allen wrote code for his demonstration on-the-fly (with the sort of mistakes that can happen using this approach), so the example was pretty basic. The takeaways I thought were useful for getting started with the technology were:
- External projects that add features to ASP.NET MVC
- MVCContrib
- MVC T4
- You can combine standard WebForms and MVC in the same solution—particularly useful if you’re trying to migrate an application from ASP.NET to ASP.NET MVC. Allen mentioned the blogging platform Subtext[10] as an example of one application attempting this kind of migration.
This talk left a lot to be desired. StackOverflow is the most robust example of what can be built with ASP.NET MVC. A peek inside even a small part of actual StackOverflow source using ASP.NET MVC would have made a far more compelling presentation.
FogBugz and Kiln
Even though this was strictly a product pitch, I’ve included it in the report because of how they implement a couple of ideas: plug-in architecture and tagging.
Plug-in architectures as an idea aren’t new—what was different was the motivation Joel Spolsky described for it. One of his intentions was to make it easier for people to extend the functionality of FogBugz in ways he didn’t want. He isn’t a fan of custom fields, so instead of building them into the core product, they’re implemented as a plug-in. He demonstrated Balsamiq integration (via plug-in) as well, so the architecture does enable extension in ways he likes as well.
Tagging isn’t a new idea either—what I found very interesting is how they apply them in FogBugz. Spolsky pitched them as a substitute for custom workflow. His idea (as I understood it) was that bugs could be tagged with any items or statuses outside the standard workflow. There wasn’t much more detail than this, but I think the idea definitely is worth exploring further.
Python: Bruce Eckel
His talk was supposed to be about Python, but Bruce Eckel covered a lot more than that. The most important takeaways of his talk were these:
- In language design, maintaining backward compatibility can cripple a language.
- The best programming languages change for the better by not being afraid of breaking backward compatibility.
- “Threads are unsustainable.”
Eckel’s talk gave the audience a history of programming languages, as well as a hierarchy of “language goodness”. For the main languages created after C, the primary motivation for creating them was to fix the problems of its predecessor. So C++ was an attempt to fix the problems of C, while Java was an attempt to fix C++. His assertion about the primary motivation behind Ruby was this (I’m paraphrasing):
Ruby intends to combine the best of Smalltalk and the best of Perl.
He made his point about the problems of backward compatibility by comparing an attempt to add closures to Java to language changes made by Ruby and Python. An article titled “Seeking the Joy in Java” goes into greater detail on the Java side of things.[11] In the case of Java, the desire to maintain backward compatibility often prevents changes to a language which could fix things that are poorly implemented. The authors of Python and Ruby aren’t afraid to break backward compatibility to make improvements, which makes them better languages than Java (in Eckel’s view).
Here’s Eckel’s hierarchy of programming languages:
| Python (his favorite) |
| Ruby, Scala, Groovy (languages he also likes) |
| Java |
| C++ |
| C |
Eckel also mentioned Grails as a framework he likes.
Another one of his pronouncements that stood out was a hope that Java would become the COBOL of the 21st century.
Eckel’s argument regarding the difficulty of writing good multithreaded code is one I’ve heard before. He pointed to Python as a language with libraries for handling both the single processor task-switching and multi-processor parallel execution models of concurrency.
Google App Engine: Jonathan Blocksom
Jonathan Blocksom gave a great overview of Google App Engine. He’s a member of Google’s Public Sector Project Team (not the App Engine team), and I think that helped him present the information from more of an audience perspective. He did a nice job of describing the architecture and the advantages of using it. Some of the applications running on Google App Engine include:
- Moderator (http://moderator.appspot.com/)
- Used by the White House to handle questions for a March 2009 town hall.
- All for Good (http://www.allforgood.org/)
- Source code for this is available here: http://code.google.com/p/allforgood/
- Source is intended as a sample to help you get started
- BuddyPoke (a 3rd-party Facebook application)
Blocksom also discussed some of the limitations of App Engine:
- 30-second time limit on asynchronous tasks
- No full text search
jQuery: Richard D. Worth
This may not have been the best talk for those already familiar with jQuery, but for me (someone unfamiliar with jQuery), it was close to perfect. The presenter did an excellent job of showing its advantages over regular ECMAScript. He used a clever trick to minimize the amount of typing during his demos by using slides with only the changed lines highlighted. The “find things then do stuff” model he explained made it very easy to grasp what he was doing as he increased the complexity of his examples.[12]
Wrap-up
After the conference ended, a “metaStackOverflow” question was added to collect reviews of the conference from its attendees.[13] The top answer (as of October 28, 2009) also includes links to slides for three of the talks, which I’ve included here:
- http://odetocode.com/downloads/devdays2.pdf
- http://www.slideshare.net/rdworth/jquery-2366236
- http://www.slideshare.net/davetron5000/measuring-agile-process-shorter-2359457
[1] http://blog.stackoverflow.com/2009/05/stack-overflow-developer-days-conference/
[2] Ibid
[3] Ibid
[4] http://gettingreal.37signals.com/toc.php
[5] http://www.amazon.com/gp/product/0060005688
[6] http://taptaptap.com/#convert
[7] This revenue model is brand-new—Apple only began to support this within the past week or so.
[8] http://www.amazon.com/Head-First-iPhone-Development-Applications/dp/0596803540
[9] http://en.wikipedia.org/wiki/Freemium
[10] http://www.subtextproject.com/
[11] http://www.artima.com/weblogs/viewpost.jsp?thread=173229
[12] Worth used http://jsbin.com/ for some of the more complex demos. It’s a very good tool I hadn’t seen before.
[13] http://meta.stackoverflow.com/questions/27367/devdays-reviews-washington-dc/27377#27377