The Six Hour Startup

On Sunday, I joined a bunch of people at a bar in Seattle to build a new web site from start to finish in six hours -- the Six Hour Startup.

One premise of the Six Hour startup (or at least this one) is that the project is decided on at the beginning of the six hours. Before I went, knowing very little and just having a link to a previous result, LunchLuck, I thought about what might a good project. One thing that I concluded was that data was an issue -- a good quick project needs a minimal amount of data.

After some discussion at the start, we settled on creating a web site to help people do the "one hundred push up challenge." The idea is that you spend six weeks doing push ups three times a week, working up to doing one hundred in a row. On the surface, it seemed pretty simple. You sign up, the site tracks your progress, maybe draws a graph or shows how you're doing relative to your friends.

Unfortunately, the data turned out to be an Achilles heel. The data itself was easy enough to get. But, the data imposed all sorts of requirements on the system that were more complicated than we thought. You see, the hundred push up challenge isn't simply about tracking how many push ups you're doing. You're trying to build up strength, so each day that you exercise, you're supposed to do specific sets of push ups -- between five and nine sets of push ups, with each set being a different number of push ups. And which set of sets you're supposed to be doing depends on how well you did last week.

Three hours in, we were still learning this. The schema, the user interface plan, pretty much everything, was based on assumptions that were wrong. That meant compromises. Had we all known the true scope of the requirements, we probably would have picked a different project. After all, six hours isn't a lot of time.

At the end of the six hours, I, and a number of others, didn't get to see working code (and it's not live now), so, in some sense, we failed. And the compromises meant that we failed in another way. Compare that with my experience at the Google App Engine Hackathon where, by myself, I built a working web site from scratch in about the same time, using technologies and a language I'd never used before. What was the biggest difference? Good scoping.

The moral of the story: What seemed like a very simple thing turned out to be much more complicated than we thought. The "elevator pitch" for the project was a lot simpler than the actual requirements. It seems like that's the case a lot of the time, even when we have a lot more than six hours.

So, was this a negative experience? Not at all. Not everything we do can be a success. It served as a good reminder on scoping, the people were interesting, and I learned some things. I'd do it again.