Code reviews have long been documented as one of the best techniques for ensuring code quality and have been cited as far back as the 90’s in seminal works such as Steve McConnell’s “Code Complete” as the go to technique.Code reviews, the worlds best defect removal tool Click To Tweet
Code reviews are so powerful that this then led to the pair programming movement, by asking how do we turn this up to 11. One of the outcomes of pair programming is code reviews done continuously and anecdotal stories describe defect free code.
“Fellow graduate student Bill Wright and I first tried pair programing when I was a grad student (1953-56). We produced 1500 lines of code defect free; It ran correctly first try” – Fred Brookes.
We Know all that
Doing code reviews is kind of obvious, they’re awesome, right? Not so fast!
If you already have code reviews as a step in you process kudos to you, the next step is to make it more effective and this post is about just that.
If you don’t have it as part of your process and have defect free code, don’t worry, you’re doing just fine. Indeed, drop me a line and tell me your tricks.
If you don’t have it as part of your process and you have quality issues. Then it might be time to discuss quality improvement techniques with your team as part of a continuous improvement/retrospective/kaizen meeting.
4 ways code reviews can be pointless and waste of time
- Not giving it the time it needs. Try reviewing thousands of lines of code over a full day. The brain will not be able to hold that level of complexity and attention in a single sitting. As the brain becomes fatigued, it will not be effective.
- Skimming the code and just paying lip service. The process says do a code review so just ticking the box.
- Reviewing formatting. The IDE can do this for you and even enforce it. There isn’t much point in doing something the machine could do for you
- Clash of egos. Arguing over implementation approach, style etc doesn’t help drive towards lower defects.
6 ideas for effective code reviews
- Time Box – Create a time box for the code review and respect it. When the timer goes off the time box and review is over. Hold the review at the same time every day so that it gets prioritised and actually happens. Keep the review short and focused.
- Check lists – Check lists are used to avoid preventable common errors in a myiad of professions from pre flight lists for pilots to surgery for medical teams. The check list could be a list is the most common gottchas for your programming language.
- Agreed standards and patterns – having agreed standards and implementation patterns reduces the clash of egos and helps the reviewers focus. Some of the best standards I have seen is a sample of code that defines the benchmark as opposed to 100’s of rules. It’s up to you to find what works, as long as its transparent and referred to.
- Fix the defects – the point of the review is to find and fix the defects. The job isn’t finished when they’re identified and tickets raised.
- Use tools – there are plenty of tools, for very low investment, out there that help support effective reviews and make the process smoother.
- Measure – understanding the volume of defects found at different stages and their causes is crucial to improvement.
Turning your code reviews up to 11
Working in pairs is highly effective. Why not try pair programming as an experiment, for a sprint, to see how your code quality changes.Try pair programming for a sprint, and see how your code quality changes Click To Tweet