Release Even Earlier, Even More Often
February 1st, 2008
If it’s a good idea to release early, release often, maybe it would be an even better idea to release even earlier, even more often.
We could have hourly release schedules, targeting our 1.0 release for the day after we begin planning. In fact, maybe we should begin coding before even specifying requirements, stakeholders, or deliverables. Heck; let’s skip those. Let’s just write code and figure out what it does later.
Doing this will potentially allow a lot more bugs into the systems, of course. But is that a bad thing? They say that it’s easier to steer a moving car than a stationary one. By extension, it should also be easier to steer a moving car which is also on fire, than to steer no car at all.
Here’s an idea: quarter-hourly “Bug Only” minor version releases. We can release the bugs before we implement the features. Who knows? If someone finds a use for a bug before it’s been fixed, we can promote it to “feature” and include it in the next hourly release. To keep things Agile, perhaps even some major version releases (on the hour, of course) could be bug releases only, with all features pushed forward to the next iteration.
After producing version 1.0, we would (of course) immediately begin work on version 1.1, and it might be a good idea to just call version 1.2, Product 2. That sounds a lot more mature. And heck, it worked for Java.
With this model, I figure the average software project will have implemented, or tried to implement, every possible feature (and related bug) within a few months, at which time it can be declared a bloated dinosaur and left as legacy code while we move on to develop the next big thing.
A plus side to this… no, wait. I can’t see one.
Sorry, comments are closed for this article.