I’ve previously worked at banks which released veryyyyyy infrequently. I’m talking quarterly or half year windows. Releases are a big fucking deal over there because if you can’t release you gotta wait for the next window a few months down road (awful I know). However, sometimes there’s a specific reason why banks or old organizations function that way.
The world’s best software teams tend to release software more frequently. This approach allows them to be more agile, responsive to user feedback, and maintain a competitive edge in the market. These teams often adopt Agile methodologies, DevOps principles, and Continuous Integration/Continuous Deployment (CI/CD) pipelines to automate and streamline their software delivery process. However, as mentioned before there are still places in different industries and organizations where slower could be better. Another caveat is that the frequency of releases is just one aspect of what makes a software team successful. High-performing teams also prioritize software quality, robust testing/coverage, effective collaboration, and continuous learning and improvement. Is one better than the other? I definitely think so but I’ll go over both of my experiences below.
Here are some advantages to releasing frequently
- Faster feedback: Releasing software frequently enables teams to receive user feedback quickly, allowing them to iterate and improve their products more rapidly. This can be called time to market, cycle time or lead time. World class teams push code hundreds / thousands of time a week. Check out my article on DORA Metrics if you’re curious.
- Risk reduction: Smaller, incremental updates often carry lower risk compared to large, infrequent updates, as they introduce fewer changes to the software at once. I was once told that releasing less frequently and going through 3 hour long calls with 50 people on a deployment is the safest method. Forget human error and large room for mistakes. Let’s make this as inefficient as possible! 😀
- Improved collaboration: Frequent releases encourage better communication and collaboration among team members, as they need to work together closely to meet tight deadlines.
- Higher user satisfaction: By addressing user needs and incorporating their feedback promptly, teams can ensure higher user satisfaction and a better overall user experience. What’s better than getting a bug fix out for a customer that is having an issue on your website?
- Innovation: A fast-paced release cycle allows teams to experiment with new features and technologies, fostering a culture of innovation and continuous improvement.
- Easier integration: Frequent releases make it easier to integrate new features and updates, reducing the chances of conflicts and issues arising from merging code changes. Stale code sucks
- It’s satisfying: When you’re crushing releases, there’s almost no better feeling the just churning out quality code and tickets that make users happy. Being stuck
Risks to releasing more frequently:
- Insufficient testing: Frequent releases may lead to inadequate testing, increasing the risk of introducing new bugs or performance issues. Sometimes there’s a thing as too fast. As long as quality is maintained this shouldn’t be an issue.
- Burnout: The pressure to release software more frequently may lead to team burnout and decreased productivity in the long run. It’s important to maintain a good culture where everyone is on the same page and can work together as a team (easier said than done)
Releasing less frequently benefits:
Advantages:
- Thorough testing: Infrequent releases typically provide more time for extensive testing, helping to ensure a higher level of software quality and stability. However, there’s such a thing as too much testing or too much manual testing in my opinion. It’s important to strike the right balance.
- Predictable schedule: A less frequent release cycle may be easier for users to anticipate and plan for, making it more convenient for them to adopt new features and updates.
- More time for planning: A slower release cycle can give the development team more time to plan and design new features and improvements thoroughly.
Risks:
- Delayed feedback: Releasing software less frequently may result in slower feedback from users, making it harder to identify and address issues in a timely manner. Imagine if it took your customers over two years to see any sort of product that they’re requesting. You’d be out of business quick!
- Higher risk: Larger, infrequent updates may introduce more significant changes to the software, increasing the risk of introducing new issues or negatively impacting user experience. For example, outages, rollbacks and high change failure rate are all symptoms of high risk, infrequent releases. Change failure rate for example is the following. I release twice a year and I fail one time and succeed the other. Therefore my change failure rate is 50%!
- Slower response to market demands: A slower release cycle may make it more challenging for the team to respond quickly to changing user needs and market conditions, potentially impacting competitiveness.
- Typically done through offhours: Yeah, this sucks. I used to deploy all of these changes in the off hours. Midnight, 7pm, after pacific time closes etc. You name it, I’ve heard it for why we can’t deploy. Releasing frequently should be painless and a quick rollback if something goes wrong. Releasing infrequently because you’re consistently scared to break your website is a sign of a larger symptom
Overall, I believe releasing frequently is an important signal for high performing teams. However, it’s not the end all of software delivery. There is a lot of context that goes into it to ensure that the organization, customers and your team are happy. However, delivering software to production once or twice a quarter is definitely signs of a potentially underperforming organization / team (again given context).
If you have any questions on the above, make sure you leave a comment or contact me for some consulting.