I LOVE building web apps which is why I find myself building CPO in my spare time after work much to the dismay of my wife, Heather. Unfortunately, what often begins in my head as a simple idea turns complex once code starts filling the editor window. So, one month into development, I’m forced to decide which of the many ‘non-negotiable’ features make the cut in the January alpha release. Why release in January? I knew early on that I wanted something, anything in production by the New Year in order to start the feedback process.

Now, the hardcore, dyed-in-the-wool software architects among you might consider this approach odd if not outright amateur. Of course you’re supposed to begin with a release date and a functional spec and never depart from either during the course of development. Ok, I have a release date and my functional specs are around here somewhere on a napkin or sticky note – I think. Normally, I start with one primary app module, let’s say the Invoicing module for CPO. First I need to be able to enter some invoices so other portions of the module can be tested with fake data. Oh, but wait – each invoice is predicated on a project so that means the project module framework should be fleshed out a little bit. Now I’m getting sidetracked. A project may have several team members associated with it – do I build the Team module now or wait ‘till later? Alright, it’s not critical to invoicing so let’s leave it for now. Back to the Invoicing module, I’m now trying to decide between emailing invoices as HTML, PDF’s or a link to an online invoice only. What about entering payment information once the invoice is collected?

My suspicion is that many of you construct web apps in a similar fashion. You begin by creating module ‘skeletons’ and then seeing how they might interact. Once the interactions are known, you think about the most user friendly way to render them. All the while you’re writing code for many modules simultaneously until that magic ‘Aha!’ moment occurs and the app begins coming to life. This sub-species of agile development (some might call it hacking) is best described in a quick read called Getting Real by the folks over at 37 Signals.

With provocative chapter title like Ignore Details Early On, Scale Later and Half, Not Half-Assed, Getting Real is quickly becoming the handbook for rapid application development - certainly among the open source crowd. Heck, you can even read it for free.

So, my task for this evening is to sit down and not get up until I figure out which features are must-have's for the alpha launch. If I can stay focused, the list should be up in a day or so. Thanks for reading.

Jeff