The adverse effect of version numbers

“We’ll fix that in the 2.0 release!” Sound familiar? To me it does, as I used to say this quite a lot up until a couple of years back when I got introduced to Scrum. Around that time I drew the painful conclusion that version numbers may have a very adverse effect: to draw any software development into a waterfall-like process and postpone the release of value.

The problem with version numbers is that they are abused for something they are not. They’re not targets, they’re not milestones, and they’re definitely not a reason to postpone delivering value.

I’ve seen a lot of situations where version numbers were actually hurting a product, postponing any release for long periods of time. The worst example I’ve come across is no release for 7 years (and counting), which is for a 2.0 release for an immensely popular VPS control panel. Until this date, any fix or improvement is being “moved to 2.0” only never to be heard from again. Another example is a product heading for a 2.0 release that never even made it and got thrown away in the end. That was, after a timespan of about two years and at least 20 2-week Sprints invested (think of how much that has cost!). In both cases, and I have to admit these are extremes, no value was delivered (yet).

Value should be delivered very frequently, regardless of a version number. Bugs or defects should be fixed immediately and should never be postponed until a “version number release” or any other value release, because they are negative value. All a version number should be is a label on something that has been achieved in the past, like the time in which you’ve ran half a marathon or like velocity: an indication of what has been achieved in the past.

Version numbers are actually very useful if used properly, because they allow you to keep track of different versions of software, a document, or something else. But if you make them more than just a label or an indicator of something achieved int he past, the very frequent and adverse effect is that the delivery of value gets postponed.

1 Comment

  1. The only good version number is a timestamp.

    -comment version 201702201141

Leave a Reply

Your email address will not be published.

*

© 2017 mpkossen.com

Theme by Anders NorénUp ↑