I’m a bit of a perfectionist. When I create something, I want it to be not only good, but great. I can’t accept substandard quality. I have standards after all and to accept mediocrity is to begin down a path which leads to enervation and death… or something like that.
Having spent most of my career on the quality engineering side, I tend to be quite particular when it comes to code reviews. My level of scrutiny can, at times, frustrate my teammates who feel I am unfairly nitpicking. Generally speaking, QA can gain a reputation for being a hinderance because we begin to be seen as an obstacle to be overcome instead of as a teammate supporting higher quality standards, but I think it’s important to realize that quality is not on the opposite end of the spectrum to speed. Quality is speed. Or, to steal from Bob Martin, “clean is fast.”
When a lack of code quality begins to surface as customer complaints, management’s go-to is often to add new processes to gate off code until all steps in that process are followed. This can take the form of either a senior developer’s approval or a centralized release committee. It’s an understandable response and one that happens frequently, despite its ineffectiveness, because it at least appears to work and as I love to say, people make decisions on what they think is true, not on what actually is.
Gating off new code changes appears to have a positive impact on quality at first. The number of issues go down, as do customer complaints, but the reason for this is primarily because the new processes discourage changes being made at all, which naturally leads to fewer new issues, and secondarily because an increased focus on resolving customer complaints can bring a short-term investment to fix known issues. In the long-run, however, the burden of an extensive review process discourages developers from making smaller changes, like paying off technical debt, and the way they do their work does not fundamentally change, which inevitably continues to lead to the same result, causing management to feel forced into leaving the review processes in place and developers who dislike the red tape to eventually seek employment elsewhere.
The real solution is counterintuitive – ship more often. In fact, the end goal should be to ship as often as possible – multiple times per day, even, and by ship I do mean merged in and deployed to production. The fear, uncertainty, and doubt that would reject making this change believes that the effect would be the opposite of slowing down and gating releases – and it is, but that is because the belief that slowing down releases is effective is wrong.
The default assumption around deploying more frequently is that even more issues will occur. But, why this doesn’t manifest in reality is because if we double or triple the frequency of our releases, developers can’t suddenly double or triple the amount of code they’re actually producing. Instead, they’re forced to cut apart the changes into smaller pieces. Less code means pull requests are less burdensome to review, less code that could potentially break, less that needs to be tested, and less that needs to be rolled back if a failure does occur.
By making ourselves ship more often, our current processes may not be able to scale. Lengthy reviews, frequent manual testing, and centralized release committees will quickly become swamped and be incapable of handling the volume because they don’t scale. These processes will have to be replaced with something more efficient and scalable – namely automation. But the part I find most interesting is that pushing for a more frequent release cycle is how we get these processes in place and not the other way around. If we want our teams to adopt the practices of DevOps and automation, we should actually be promoting a faster release cycle as our first step. If your team currently deploys once per month, push for once per week. If you deploy once per week, push for 2-3 times per week. This is the most effective method because finding better processes becomes a necessity instead of a “we’ll get to it eventually” item to throw on the bottom of the backlog. Start by increasing the frequency of your releases and all else will soon follow.
Adam Lif 