Nobody will pay for code reviews.
No, the client will not pay for code reviews!
You have worked for many years for companies that did not believe in code reviews. Even though your company introduced some kind of SCRUM (because everybody does and “we want to be agile now”), code reviews were basically ignored. Nothing was enforced, hardly anything was checked. The faster, the better. Your product manager would ask you: “how much time do you need to implement the feature?” then multiply it by 1.5 and pass the estimation over to the customer. The project, however, would take three times as long and at the end the customer was happy that the functionality was there at all, the project manager was happy the bill was paid and nobody even mentioned code quality.
Nobody forbids the developers to review their code
Developers are lazy animals. Or let’s call it “optimised”. They will not do what they are not explicitly asked for, especially if there’s a deadline ahead. They will not update documentation. They will not write a test suite. They won’t do proper QA. They will not even test marginal cases. The burden of maintaining any code quality lies indirectly on the customer then, poor devil. And they will certainly not execute a code review because everybody is busy and behind the schedule, anyway.
However, code reviews are just another, maybe the most effective means of keeping your programmers accountable. In front of the customers, the company and the developer herself.
You know that and after some time you look for another company because you believe that the things should be done in a different way. And then they say….
We do proper code reviews here
So the first thought is (should be?) “Great! finally! some serious people here!” After all this time working in a mediocre environment, producing mediocre code and the company being rated mediocre by your clients, now there’s a welcome change. And the code looks pretty good! it’s readable! it’s concise! Methods are short and crisp! And, wait, you even understand what the code does!
What are you doing to my baby!!!
So you get into the process and start writing your own code. Partially you base it on your experience, partially on stackoverflow and sometimes you ask your colleagues to help you out. Then you finally commit. You’re satisfied with yourself. Perhaps you don’t expect awe and adoration, not even appreciation, but at least acceptance. A few minor adjustments and your code gets in. So you lean back and wait for the reviewers’ comments. And they appear, drop one by one. Apparently you screwed badly, everything what you’ve written was wrong, your innovative ideas were crap, yours and everybody’s time was wasted. And then you cling to the few pieces of your code you were especially confident about, that cost you the most research and that seemed so much better than what was written before. You start a pathetic attempt to defend the code but there is no ally to support you, your arguments just don’t get through and you know your case is lost. You utter a cry of despair (internal cry, of course): “What are you doing to my baby, you’re killing it!”, only to condescend and rewrite the code. Then after finishing work on that day you go to the nearest pub and drown your sadness in a bottle (well, got carried away with my imagination a lil bit).
Whaaat? the code review takes five times as much time as writing the code itself!
It took you a day to write your code. It was pretty fluent and pretty straightforward. No black magic with the assignment, there were not too many things that could go wrong, not too much potential for improvement, even. And then the code review goes on… and on. You try to correct your code as fast as possible, to finally get the approval, but your colleagues find new things all the time. Some of them are obvious mistakes you’re wondering how come you haven’t noticed before submitting. When your first and most critical colleague is through with you and you’ve considered all of her comments, the next one makes your life hard and your self-esteem at the Dead Sea level with another one hundred remarks. So what you do the next two to three days is constantly correcting and resubmitting your code until finally finally finally nobody has a problem with it. And then, in the end, you finally merge your change and can go on with your new assignment. With a rather bland feeling.
And so it goes for some time, development, submission, tons of comments, resubmission, tons of comments, until your code is so much different you cannot recognise it anymore.
The critical moment
And that’s the stage when lots of teams gave up on code reviews, especially if they weren’t officially enforced. I mean, the code worked ANYWAY, the customer doesn’t care and the reviews took so much time nobody was ready to pay for. After all it is your responsibility, as a developer, to write proper code. Yourself. And then you spent so much time and there are no new features.
And so you endlessly follow the path to enlightenment
Some time passes and you notice that some things that you fiercely defended do not make so much sense. Maybe they don’t make any sense at all. You appreciate the overall consistency and testability of the application code which is a product of the review. You learn the ways how to make your code ready for future enhancements, and, at the same time, how not to introduce functionality that maybe nobody is going to use in the future. You like the tension between different “personalities” of your colleagues because this way one of them is more analytic and another just looks at the bigger pictures forges a product that is “near perfect”. You always learn a new perspective when you discuss the possible solutions and in the process of exchanging arguments you can balance all aspects of the code.
You will still keep on losing your “babies”, your code will (have to?) be completely rewritten on occasion. And mind you, The code is not “your baby”, it’s a property of the company you work for. So it should not mirror your own ambitions but rather suit the team and the customer the best in a longer perspective. And your effort was not wasted. You have learnt new things and new paths and maybe you can use the knowledge the next time. Or at least know what is the wrong way.
Sometimes the code review will still take many hours or days and yield so many comments and objections. But it’s still cheaper than fixing all of these bugs and confronting the displeasure of your customer. To say nothing of the peace when you know the next developer who takes over your code will not hunt you down when you’re asleep because he’s so frustrated with your messy code (got carried away, again).
And yeah, sometimes the code that was perfectly fine months or years ago will not be so great anymore. Because you and your team grew and because the constant sharing of knowledge and even all the frictions during the process let you walk the path to enlightenment that helped you to write better code and become a better programmer and architect and understand the customers’ requirements better.
And that’s the beauty of code reviews.
