Releases are painful.
That is a generally accepted “fact” in many parts of the software industry. Yet it needn’t be so.
Releases can be painful. If you release functionality in a “big bang” style, once per quarter approach, then don’t be surprised if the experience isn’t everything you’d hoped it would be.
Like anything in life, the more you do something, the more you learn, and the easier it becomes. Practice makes perfect. By the same vein, breaking big things up into small chunks often makes them easier.
Take running a marathon (uh oh, bad metaphor coming up…). If you run 26.2 miles in one go, then it’s hard work! If you run 26.2 miles every month, you’ll find it easier, but if you only do it once in a blue moon then chances are you’ll hit a wall at some point, pain will set in and you’ll wonder why on earth you signed up for this nonsense.
Take that same 26.2 miles though, and, let’s say, you run it in 4 parts. Run one part per week for 4 weeks and you’ve finished your marathon. Yes it took longer (did it?), but it was less painful right?
I said it took longer… but that’s not necessarily true. Perhaps you ran the last mile at around the same time you would have anyway, but you ran the first mile a month earlier because you didn’t feel you needed to train as hard or as long for the whole thing?
Because you were running in smaller chunks and resting inbetween, you probably also ran a bit faster. So you were running for less time overall!
To stretch the metaphor to its limit: you probably spent less time running and ‘delivered’ your first miles around 4 weeks earlier than you would have if you did it all in one go.
Still with me? OK, back to software…
By releasing smaller chunks of functionality more frequently, you are able to release them earlier, before everything else is ready to go.
Smaller releases generally take less time too. Because there’s less to push out, less to validate and check, and (in theory) less to go wrong.
Finally, through the act of releasing more often, you learn more about the process you go through, are less likely to make mistakes, and are probably more willing to put the effort in to streamline the process through more automation.
Overall, releasing little and often is a win for you, a win for your team, and most importantly a win for your product and your users.
Ralph Cooper, Head of Software Development
