Code review is one of the most important aspects of developing yet it is so often jettisoned in favour of, well, in favour of not reviewing code. As writers of code, developers are just like every other poet, blogger, or journalist. They write their script, tweak it, rewrite it, agonize over syntax, and eventually push it out into the world. The difference between developers and all other writers though is that editing of what you have written is not automatically accepted as part of the creative process. In all other forms, it's not done until it's reviewed, and it is accepted that you need your peers to review, catch typos, tighten up phrases, and to point out oversights.
Developers are sensitive souls though and after getting something to work, often overcoming many obstacles in the process, they proudly point to the software and exclaim "look, it works". In their moment of triumph, the last thing they want to hear is, "the code quality has to be improved, you need to refactor it".
This is because, and here comes that really annoying failed artists phrase, the medium is the message. In writing the way something is written affects the message, whereas with code, the way something is written does not affect how it works, until it does. Down the road a security exploit, an unexplained error messages, a duplicated callback, a memory leak under heavy load, and "look, it works" suddenly becomes, "Look, it's a bug". Will you really be able to get away with the line, "it's not a bug, it's a feature"?
If this sounds like a common scenario, then you need to improve your coding work flow, and make collaborative code review a key component. It is essential to improving your coding practices and developing your own skills, both technical and personal.
To put it in sporting terms, code review is like tracking back when an attack breaks down, or covering a position while a team mate gets their breath back. It is not glamorous, the ignorant in the stands do not appreciate it, and there is very little glory in it. But at the highest level, you will be destroyed if you do not do it and you won't become a better player if you do not get out of your comfort zone. But that begs the question, why do you almost never read about code review?
The answer to that is very simple; It's a competitive advantages that no company wants to reveal.
Benefits of Code Review
Firstly, let me quickly list some direct and indirect benefits of code review as cited by companies that actively undertake a comprehensive code review strategy.
Additional benefits arising from the creation of a collaborative development environment are:
- Synergy: Teams find faults that no individual reviewer would be able to find.
- Competition and Cooperation: It's fun, and the mixture of competition and cooperation between team members leads to everyone trying to improve both themselves and those around them.
How to Code Review
The secret to getting the most of your code review process is to get it as close to the time of creation as is beneficial, preferably within the hour, and to do it in bite sized meaningful chunks. This is investigated and explained thoroughly in the white paper, The best kept secrets of peer code review, where the authors dig deep into the topic. The main tips can be generally summed up as follows, and the first 3 bullet points actually remove 21% of code review requests:
- No reviews that require less than 30 seconds
- Don't review when the inspection rate is greater than 1500 lines of code per hour
- Don't reviews where the number of lines under review is greater than 2000
- Reviewers work best below 200 lines and produce relatively high defect rates
The Economics of Code Review
The paper further outlines the the economic impact of the development stage at which bug are caught. This makes a very compelling case for introducing code reviews based on costs alone, not even including the ancillary benefits:
- Development Stage
Getting it right first time, building peer reviews into development, and not creating bugs in the first place is proven to be the cheapest and best way to build a product. It not only increases the quality of the software, but through knowledge sharing educates the development team, making them a much more valuable asset.
- Testing - Software Quality Assurance (SQA) Stage
Obviously SQA is needed to apply stringent tests, catch edge cases, and push a product to breaking point. This is good practice, but it should be kept at a demanding level. SQA is time consuming, and additional time needed to get the context of code means testers must re-read all the code to catch those syntax errors and duplicated requests. This makes catching bugs at this point elusive and relatively expensive compared to catching them before they made it to test. So, make sure it is valuable bugs that are caught in SQA, and not time spent cleaning up shabby code which can leave testers unable to see the wood from the trees.
- Customer Stage
It's out, the code is live, and now it is expensive. There is no relative here, you will lose money in absolute terms. In addition to tarnishing your reputation, and the fact that it could even cost you a contract should it blow up in someone else's mission-critical system. You really don't want your customers catching bugs in your code. Nothing is worth losing your position in the industry, and nothing wrecks your ambition quite like damaging a customer's sanity.
So what tricks do you need to use to ensure that no bugs get introduced into your products? The answer is simple; every trick in the book, including code review.
Overcoming Code Review Implementation Obstacles
Implementing a code review process can cause some unforeseen issues, and according to research, the two biggest obstacles to code reviews are:
- Programmer Egos
Developers fall into two categories, much like everyone; collaborators and isolationists. Collaborators obviously benefit from peer review and embrace it. Isolationists though continue to work unproductively on a problem they can't solve rather than reveal to their peers that they need help, and as a result their average career in high-tech lasts just 8 years because their knowledge becomes constrained to what they can figure out on their own, which even for the brightest individuals, in a field of bright individuals, is limited. This is where as a manager or team lead you could use the North / South Korea example to get the message across, you could end up working with Samsung or Dennis Rodman depending on your life choices.
To succeed programmers needs to work in teams, listen carefully, take risks, and learn from their mistakes in order to survive in typically fast-paced environments. Continuous learning, along with sharing knowledge and assessing feedback, enhances and sharpens your skills, and allows programmers to continue to have a rewarding career. If your ego is getting in the way of your team work, then you're in for a very bruised ego sooner rather than later.
- Packing Source Code and Meetings
The hassle of packaging source code and scheduling review meetings is the second blocker than turns people off collaborating. While tools exist to automate packaging, chairing meetings, and making the most out of them requires preparation. Something many people don't bother with, and think the first 15 minutes should be spent reading the agenda. I recommend leaving that kind of meeting and telling them so come back when they are prepared. Sometimes you have to be cruel to be kind. Creating a positive meeting culture is a whole different blog worthy of it's own post, but this statistic should help sharpen the minds of the unprepared:
- 4% of bugs are found in review meetings. So if you can't run a good meeting, don't waste time on a bad one because 96% of bugs are found outside of it. Let your colleagues work instead!
Conclusion
Proper work flows and collaborative code review practices are a competitive advantage when done well. Much like Coca Cola's secret recipe, you won't ever be told what is going on behind closed doors at the best software firms because it is their secret sauce. But the value to an organisation of investing time in creating the right development environment and collaborative ethos will reap both unquantifiable rewards, and concrete results. From a happier more engaged workforce with more proficient and collaborative developers, to quantifiable results such as more stable code, less bugs, and faster time to market.
The research backs up the claims. Get your code review processes sorted out, champion the cause, and ensure it is beneficial to everyone involved. When you start to work like the elite of your industry you may eventually become one of them, but only if you work hard enough and smart enough.
Brian