Launching Puzzazz

A month ago, I attended a Hackathon for Google App Engine at Google in Kirkland. I came away pretty impressed. During the Hackathon, I started a brand new project, Puzzazz. I literally started from scratch. I had to learn Python, Django, App Engine, and a few other things. I built a puzzle tracking system, a mini social network, and a bunch of other things. I even wrote some new Django middleware in the process that I'll probably release as open source.

After the Hackathon, I stole time in the evenings and weekends to finish the project, with the result being that I launched Puzzazz this morning at 12:01 AM Pacific Time.

I'm still impressed with App Engine. Sure, there are some limitations, some significant. Some limitations are because it's a preview release and some are fundamental design decisions related to the highly scalable architecture. Others have written plenty about the limitations, so I don't see the point of rehashing that here. But, as a result, App Engine isn't for everyone or every app. However, for those that fit the model, it's a powerful, game-changing tool.

I like App Engine so much that I'm going to use it for a very intensive project that I'll be starting in a few days. I'm not ready to share the details quite yet, but I will be blogging about it every day once I get started.

If you're wondering what exactly Puzzazz is, here's a brief summary from the About page:

Puzzazz has a simple mission: to give people who like puzzles a quick, fun diversion every day. Whether you're a casual puzzler or a serious puzzle addict, Puzzazz can fill the bill.

As a bonus, Puzzazz users can invite their friends to join in for some friendly competition. If you're a Twitter user, you can even have Puzzazz automatically tweet for you whenever you solve a puzzle.

If you like puzzles and, particularly, word puzzles, check it out. If you have any feedback, I'm happy to hear it. More details can be found in this post on my thisTangent blog.

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.