Code Reviews


Code reviews are a best practice developed back in the early 1970’s by Michael Fagan.  He was a computer hardware engineer by training and knew from experience that reviews in his previous field found quite a few defects before a hardware spec was sent to the factory to be burned onto silicon.  It was expensive to undo defects once the spec had been sent to the factory and reviews were a great tool in catching defects early.  His original paper describes the “Fagan Inspection”.

As time has gone on, more papers and books have been published on the subject; most notably Handbook of Walkthroughs, Inspections, and Technical Reviews by Daniel Freedman and Gerald Weinberg in 1990.  The best current source for how to do reviews is the IEEE Standard 1028 for Software Reviews and Audits.  Regrettably, the IEEE does not make their standards free to access, which I think diminishes their use and ultimately their importance.  In it they describe four types of reviews: a Management Review, Technical Review, Inspection, and Walkthrough.  I have taken these four descriptions and amalgamated them into a review procedure that, I think, brings the four procedures together nicely.  I post it here for your edification and use.

Code Review Policy & Procedure

CAST Study shows software industry still has a long way to go


CAST’s recently released “Worldwide Application Software Quality Study” is the first study to give real numbers, based on a good amount of data, to code quality.  This is a notoriously difficult problem to address given the millions of lines of code most applications have.  They do a very admirable job of not going too far in their assumptions; but also delivering valuable results.

A key finding for me was that code quality does not go down with increasing lines of code (p. 10); unless you are using COBOL.  Thankfully I don’t :).  What did cause code quality to go down in modern languages (Java, .Net, etc.) was module fan-out.  It seems that David Parnas’ theory of modularity has won out in modern languages; as it is encouraged in the language design.  But this has produced the un-intended consequence of developers creating too many complex dependencies between modules.

The study also puts a price tag on maintaining code that all bean-counters will love.  But is also gives real research for developers to point to for getting more time and money to re-factor code.  I highly recommend this study.