Code Review – 3 Reasons Why Your App Deserves It

Do you want to find out the single best way to greatly reduce the costs of development? Would you also like your app to of an excellent quality and be easily maintainable, even long after the release? Perhaps you even want to know how to utilize a process invented by industry giants, such as IBM or NASA, and adapt it to the Agile methodology? If yes, read on.

In this article, we would like to tell you about the process of peer code review: what it is, what it is not and why we believe its presence is crucial for successful software development.

Rationale

To make mistakes is human. No product has ever been flawless in its first iteration. That’s why authors are always supported by editors. Software engineers would be foolish to think any different. Believing one is capable of single-handedly always delivering bug-free code is a sign of juniority and only leads to problems further down the line. That’s where code review comes in. It is a process of inspecting other people’s code with the aim of finding any defects as soon as possible. It does not replace quality assurance but rather serves as an integral part of the overall process, along with manual and automated testing.

Quality comes at a price. A very small one.

When it comes to the topic of code review and project costs, the majority of articles regurgitate the same old data. Supposedly finding and fixing an error in the early stages of the software development cycle is up to 1000 times (a thousand times, yes you read that right) cheaper than in the later stages[1]. While such an exponential increase was true for waterfall projects and even Agile ones a long time ago, it has since been debunked by the very same person who invented it. The difference is still present but significantly smaller, reaching up to 5 times[2].

Why is it, then, that some blogposts still use the old 1000:1 ratio? Simply, a bit of fearmongering usually helps them with their sales pitch, be it for testing services or custom code review tools. This article serves no such purpose and aims to be objective and informative: thus, we’ll base it on accurate and current data.

More than half of all bugs get discovered through reviews

A simplified software development life cycle looks like this: specification, design, development, testing, implementation and maintenance. Specification is usually prepared by clients, so the earliest place where the development team can make errors is during the design and development phases. Code review happens exactly then, before any documents or code gets committed into the project.

Research shows that more than half of all bugs get discovered through reviews. The exact numbers fall somewhere between 60-85% [3,4]. Furthermore, reviews usually uncover errors which would be hard to find through any other means. Combine that with the knowledge from previous paragraphs and it becomes obvious what a tremendous amount of costs can be saved thanks to code review.

Code review saves time and money

So far so good, but one could ask how much does code review cost in itself? Is it worthwhile? After all, it takes up the precious (and costly) time of developers – about 10% of it, to be exact. This sounds like a lot, but consider the following. Finding a bug in a review is a short process: read the code, find an error, point it out and fix it. Finding a bug during testing or even after release requires more steps: find a bug, try to reproduce it, find its source, fix it, test it and release a new version. Longer time = higher cost. That’s where the aforementioned 5:1 ratio comes from.

All in all, it cannot be disputed that code review saves time and money.

Maintenance. Do not underestimate it.

From a developer’s perspective there are few things more frustrating than having to take over and maintain a poorly written project. From a business perspective, there are few things more costly than having to rewrite a whole app because it achieved a state in which it is virtually impossible to update and support. Think of it as an engine that drives your business. A literal engine. Would you rather have it be neat and tidy, well oiled and easily modifiable or a greasy, monstrous contraption where you can’t touch anything for fear of something blowing up?

An app is never fully finished. There are continuous updates, fixes or migrations to new versions of operating systems. That’s why an easily maintainable program is so important. This is accomplished through adopting a uniform style guide and adhering to common good principles, such as SOLID or DRY. Code review is the only way to ensure that all programmers follow the aforementioned practices.

Education. It is better to work together.

A side effect of code review is, broadly speaking, its educational value. While not easily convertible to expense reduction, its benefits to the whole team are priceless. We believe it does not need to be explained why having better employees is good for any company. Code review enables developers to learn from one another. Through reading others’ code, one can study new techniques and solutions. This is especially helpful to junior members of the team who can draw from years of their colleagues’ experience.

Additionally, software is usually written in modules, with each person being responsible for only a part of the product. Checking other people’s code ensures that all developers have a unified understanding of the greater whole. This is important, because it helps reduce critical paths as well as the rather dark bus factor.

Another social aspect of code review is the Hawthorne effect. In the software development world, there is a common situation wherein programmers write better code because they know that their peers will see it and check it. It is a very healthy and natural thing, which leads to increasing the final product’s quality.

Conclusion

Many people say that code review is the single best thing a developer can do to improve their code. We believe it applies in the same way to the business side of apps. Its effects on quality and long-term maintainability are invaluable. It helps keep the costs low and allows the team to share knowledge constantly.

Here at Droids On Roids, the practice of code review has been present ever since our first project. We cannot imagine working without it! The advantages are obvious to us and we want other fellow programmers as well as business owners to reap the benefits from this process. Hopefully, this article has shown you why every software project deserves code review.

If you would like to see exact tips on how to implement it – stay tuned for our next post!

References:

1. Boehm, Barry W. and Philip N. Papaccio. ‘Understanding and Controlling Software Costs,’ IEEE Transactions on Software Engineering, v. 14, no. 10, October 1988, pp. 1462-1477
2. Beohm, Barry and Victor R. Basili. ‘Software Defect Reduction Top 10 List,’ Computer, v. 34, no. 1, January 2001, pp. 135-137
3. Stacy Nelson and Johann Schumann “What makes a Code Review Trustworthy?” In Proc. HICSS-37
4. Jones, Capers (June 2008).”Measuring Defect Potentials and Defect Removal Efficiency” (PDF). Crosstalk, The Journal of Defense Software Engineering. Retrieved 2010-10-05

Related posts