500th Post

This is my 500th post. I put off posting it all week because I wanted to post something lofty and clever. But in the end, the great is the enemy of the good - if I wait until I have a really good post, it could be weeks before I have time to write a 6000 word treatise on the relationship between quantum physics, shaders, and the price of crude oil.

The decision to publish less now or more later always comes up in software release planning - once the resource budget for a project is fixed* the only choice is ship sooner with less features or later with more features.

With both X-Plane and WorldEditor we often choose "ship now with less" for a simple reason: we are going to ship with more later, but if we ship now with less as well, people get some benefit in the meantime. WED is a perfect example: the first version could only edit airports, and shipped almost 18 months ago. Had we waited until we had overlay editing and airports, we would have had a more impressive release, but authors would have had no editing at all for 18 months. Why force the people who want to edit airports to wait 18 months for overlay features?

(An assumption in this is that the cost of actually doing a release is fairly low. Obviously we don't want to do a new release every single week!)

There is a contrary force that might argue against frequent releases: once we change a feature to make it better, users are surprised if we don't make it perfect. Users assume that if we fix some bugs in a feature but not all bugs, that it's because we didn't know about the bugs we didn't fix. (The truth is usually that we had limited resources.) This produces a very strange situation where users are sometimes happier with a product that is less featureful/more deficient/more buggy because a small improvement in real functionality introduces an expectation of a large improvement.

A second behavioral phenomenon amplifies this: in my experience users consider new bugs to be significantly "buggier" (for lack of a term) than bugs that have been around for a while. This is perfectly understandable: humans are very adaptable and we get used to a bug over time to the point where we may not consider it as "bad" as when we first saw it. Trade the old bug for a new one, and we have to become re-acclimated.

These two behaviors argue (particularly when bugs and limited functionality are involved) to make a small number of large changes that move an aspect of the program from one 'stable' configuration to the next.

* If you think that more resources can break this trade-off between features and a quick release date, I strongly recommend "The Mythical Man Month". The short version: 9 women can't have a baby in 1 month - if you want a quicker release you have to do less.