Code reviews have in the wrong environment enabled engineers to relieve themselves of the accountability for writing good code, turned technology leaders into powerless whiners, and enabled managers to ship on time crappy products while remaining blameless for the crap.
Much like the great filter that supposedly eliminates civilizations, code reviews are supposed to eliminate bad code and in the process of being used in that way, eliminate good code as well. The net effect is that the code reviewer is reviewing crap all day. And as a technologist that is very very annoying.
Let’s step back.
A lot of management culture in many large organizations is focused on making sure the lazy ass employees do their jobs correctly. The theory being that at scale, the average employee is … average.
Given the average nature of the average employee, then how do you make sure that the quality doesn’t degrade below average?
Hold the managers accountable for the quality of their work.
In tech companies, a key part of the work of engineers is writing code.
The approach some companies take is to have the managers accountable for the quality of the code.
The problem is that managers are also accountable for shipping on time. And the pressure to ship on time creates an unbearable pressure on the the managers to create a culture that pushes for date over quality over code.
The solution is to create a separate set of leaders who are responsible for technology quality, people like me who have titles like Distinguished Engineer, Architect etc.
The theory being that the tension between the technology leader and the manager will result in solutions that meet the business requirements for both date and quality.
An unfortunate outcome of this process is that the technology leaders are then tasked with ensuring that the code quality is good enough because that is their job. And the process that is used to ensure that code is good enough is the code review.
The problem, and this drives me nuts, is that in the wrong hands what happens is the accountability for the quality of the code is on the reviewer not the author.
A big bug escapes and the first question isn’t:
Who wrote the code
but
Who reviewed it?
Who tested it?
This creates a perception that the author of the code isn’t actually accountable for the bug. The author is, even though they wrote the code, blameless.
This makes the reviewer of the technology the organization’s bitch. On the one hand you’re accountable for the quality of the technology, on the other hand no one reports to you, and managers decide bonuses.
Guess what loses?
Yup, the quality of the technology…
How do you fix this mess?
The first is that you need to change the culture of what a code review is there for and you need to change the relationship between the manager and the technologist.
The code review has to be not about finding bugs but improving the overall quality of the product being produced. The way I like to describe it, everyone is supposed to be doing their best work, and reviews are to make great work better not filtering out bad work.
The manager and the technologist have to both be responsible for the quality of the technology and the date. If the project misses the date or the technology sucks they both failed.
Returning to the title of my post, code reviews when they act as a filter instead of a booster reflect a dysfunctional organization that is broken at it’s core. And the reason I have hated code reviews is that the problem wasn’t the review, the problem was the underlying first principles that motived their existence.
Leave a Reply