Photo by Nicolas Hoizey
Modern software engineering is all about shipping fast and often
It was about a month ago that I was introduced to a book called Accelerate and later discovered another study Accelerate State of DevOps Report.
It is all natural to agile teams today but what all these studies demonstrate is that engineering teams that deliver more often are more likely to meet or exceed their organizational performance goals.
I remember when I was in a demo meeting with a large organization and when they discovered we deployed sometimes over 5 times in a single day, their first impression was “okay, your software is not stable!” this claim was totally against our uptime rate, 99.99% on all servers!
Shipping fast and often has numerous advantages, it is a simple logic actually, frequent releases mean smaller batches being deployed therefore less risk of failure or downtime.
In the event of failure, fast releases mean fast recovery from failure.
In your team in order to have high performers, they need to be able to quickly get feedback on their work quickly. This is where code review comes in.
The benefits of code review are many. First and foremost, it helps catch mistakes. Having someone else look at the code can help you find errors that may have been missed at that pace. It can also help find cleaner and optimal ways to write code and make code more readable.
Code review also helps to build a shared understanding of the codebase to be able to recover from failure events. By having everyone on the team look at the code, they will all be familiar with it and will be able to make changes to it more easily.
Finally, code review helps to build a culture of collaboration and feedback in your team.
In short, it took a long time for software engineering teams to understand traditional approaches such as the Waterfall model might not work best in software development as it is beneficial for additional engineering. Simple because building pace doesn’t have a correlation with the size of a potential failure, hence allowing you to recover faster!
This is a very controversial topic in software engineering and engineering management, what is your experience?