Bugs can be introduced anywhere in the software development lifecycle, from the early stages (requirements gathering etc) right up to the final shipping of the project. The most expensive types of bugs to fix are those introduced earliest and fixed latest. For example, a design error that needs to be fixed once the product is live in the field, is very expensive to fix. Whereas a coding error found and fixed the day after it was made, is the cheapest to fix.
Since large amounts of software development is commercial and needs to demonstrate profit, reducing costs and increasing margins is essential for success. However, even open source projects or the hobbyist writing code in his/her spare time can benefit from reducing the “cost” (meaning effort and time) of fixing bugs.
I was once told by a senior engineer that reading the comments written by a developer can often shed light on what the coder was trying to do rather than what they achieved. The key to his advice is that when a programmer needs to explain their design or implementation, it forces them to re-think and quantify their work. The very act of starting design and code reviews actually forces engineers to re-evaluate their work and in doing so can reveal bugs and flaws previously hidden.
Two heads are better than one
Applied to software engineering this means that by employing a system to peer check and review software design and implementation, the resulting work will have been verified and validated by at least two people, reducing errors. If this is expanded to team level peer reviews, with multiple participants, then the number of errors found (and subsequently fixed) increases.
However a successful design and implementation review needs to start with the correct attitude. Most people (and maybe engineers more than others) become hostile when subjected to reviews. The key to making these reviews effective is for each member of the review to adopt an attitude of “united we stand, divided we fall.” The goal is not to criticise but rather check, validate and verify. The aim is to work as a team for the greater good of the project.
Level of integration
Using a code/design review reduces costs simply because the more integrated any component is, the wider the impact of changes. The wider the impact, the higher the costs. Code which hasn’t yet been committed to the source repository has the lowest level of integration. Fixes at this point are low impact and low cost. Code which is incorporated into a working system, has a high level of integration and a subsequent high level of impact. Changes to that code now (to fix a problem) impact other parts of the system which increases the resulting cost of the fix.
This “level of integration versus cost” rule applies even more to design flaws. A running system containing a flaw in the design of one of its components demonstrates a high level of impact due to its high level of integration. Imagine a database, network protocol or work flow which needs to be changed. The change to this fundamental system component has repercussions across the whole system resulting in high costs to any changes.
Conclusion
Using peer design reviews and peer code reviews reduces the number of bugs and the associated cost in fixing those bugs. Handled correctly they are a valuable tool in making the SDLC and overall project a success.
