Part One: How often is too often?
It’s the 21st Century, it’s been the 21st Century for eighteen years now and frankly, we’ve gotten over it. From re-ordering our weekly takeaway at the press of the button to summoning a car to our door, it’s all instant now. As consumers, we’ve moved past thinking about computers and smartphones to just using them. It’s intuitive, easy and just part of life now. But what about the software that powers the new age? How often do you need to upgrade an app? How often does the website you look at everyday suddenly change? And when the changes happen, does that excite you or scare you?
Similar, to how terrestrial TV has been eroded by on-demand services, consumers expect more new “content” to digest and experiment with on a regular basis. And they expect that content to just work. When releases go right, they can be like a sequel to your favorite movie or a new series of a TV show, they make you excited to use the software and keep you invested in it for a long time coming. Even if they go wrong, releases keep consumers engaged and help sustain a community around a product.
But getting releases right has never been simple and is no simpler now that customers interact with systems in a different manner than they did a few short years ago. Just because a service exists in the “cloud”, doesn’t mean adding new features is as simple as looking up at the skies. So, what’s the best solution? Well some decided to throw away the old strategies of their predecessors and embrace the radical:
“Move fast and break things.” – Mark Zuckerberg
This was the antithesis of everything decades of software engineering experience had stood for. And for good reason. Breaking things is terrible for user experience, means redirecting time and effort to support and operation teams instead of development and can even lead to legal problems if you accidently expose consumer data or don’t think through the implications of new features and how they can be used. But moving fast is important; failing to do so will paralyze your business. So how do we answer the question of how often to release?
The old way – I’ve been in projects with quarterly release cycles and the problems that generates can become crippling. Long release cycles increase the risk of bugs and reduce your ability to innovate and compete with rivals. The longer the cycle, the more code is written. Thus, the larger amount of time has to be spent on testing and the more unpredictability is introduced into the code base. It’s very difficult to keep track of 3 months’ worth of changes, and huge changes like this very often require lots of work to redeploy. Even in a micro-service architecture, 3 months of changes is likely to have an effect on every part of the system.
Little and often – By contrast, cut down the release cycle and everything gets simpler. If you only have a couple of weeks to develop a feature, that feature is much more easily contained and much easier to plan. The effect this has on every stage of the software lifecycle is profound; if each team involved in getting a product out of the door is aware of everything in the release then that helps improve the quality of the product, the speed of deployment, the documentation around it and the marketing for it.
Regular but not rigid – There’s a lot of benefit to be had by making a release calendar driven. Pick a date like “we release on the last Friday of the month” or “we release every other Thursday” and make sure everyone knows it, both customers and internal teams. The predictability and reliability of the release calendar helps everyone to plan around releases and builds trust between you and your customers. If your releases are regular enough, then that allows your organization to stop fretting about rushing a big feature out of the door. If it’s not ready, then let it wait till the next release. Sure, you may annoy some customers but as long as you’re still releasing even minor improvements then the wait time won’t anger many. And if your logic is always about improving the quality and getting something done right, then that’s hard to argue with.
What your customer wants – Never forget the golden rule: the customer is always right. Don’t be shy about asking them for their opinion, they pay for your services so they probably care about how often they get new updates. A typical rule is that enterprises prefer less frequent releases to reduce risk and smaller businesses will be happier with more frequent updates, but this may not always be true. Ask them, and then structure your plans around their responses!
To sum up, having a smart release policy will focus a platform and product and make everyone happier. It’s worth seriously considering the frequency of releases and taking the opinion of all valid stakeholders into account. Getting releases right is one of the great challenges of a technology business but doesn’t have to be so scary. If release management is given its proper focus, and placed into the core of the business calendar, then it can help enable the business to engage with customers and outshine competitors.