A release is a release is a release

Times they are a-changin’.

A decade ago, in computer’s pre-touch dark ages, you had to think hard when you were about to push the release button at the end of your development phase: How many people will be affected by this defect you knew about? How many people will miss that feature that hasn’t been implemented yet?

Today, we still have to ask ourselves the same questions. But in contrast to ten years ago, our answers will less often hold back a release. Why so? Because in many cases, the correct answer to the questions had been “I don’t know” – and it still is today. When software distribution was utterly difficult, this lack of knowledge forced us to err on the safe side: we had to fix this bug and implement that feature, because distributing updates was too slow and too costly. But what if users never even saw that issue or didn’t want that feature in the first place? Then we delayed our product without any real need.

It’s so much easier to distribute our software products now. No more floppy disks to copy, no more DVDs to burn, no manuals to print, no pysical shipments to take care of. Just upload your code to a server, sit back and (more or less) relax. When we discovered a defect in our Wednesday’s release, we created a new release on Thursday. And just 26h after the buggy release hit the virtual shelves, the corrected release had replaced it globally. And no, that’s no theory, that’s just what happened this week. I loved it! 🙂