An Ounce of Goat or a Pound of Hero: Software Reviews and Inspections

[article]

just a few:

  1. Code reviews and inspections. Code review is probably not on anyone's list of exciting ways to spend a few hours, but its reported 70-80% find rate certainly deserves attention.
  2. Automated Inspections. For the lazier among us, there are tools that will automatically inspect code for suspicious constructs.
  3. Unit testing. With the emergence of extreme programming, unit testing is now in fashion.

Early Detection vs. Late Night Heroism

  1. Early detection tools cost much less than finding showstopper bugs at the last minute.
  2. Early detection methods find bugs in a simple and boring way, which is good. Software development currently has too many nail-biting moments and death marches.
  3. Early detection tools require planning. Once you are in reactive mode, it's too late.
  4. These tools do not find all bugs. You still need testers and developers to fix bugs-hopefully not as many since the number of bugs will be smaller.
  5. Measuring the impact of these tools can be tricky since their real value is in preventing worse bugs down the line.

Keeping It All Under Control
Being a hero is great, but only if your heroism doesn't involve a situation you could have avoided in the first place. Good engineering doesn't consist of random acts of heroism. Good engineering should celebrate a subtler form of accomplishment.

Further Reading

  1. For quick background on the effectiveness of code reviews, read " Inspections - Evolution and History: 1972-2001 " by Michael Fagan
  2. JUnit and www.NUnit.org provide good starting points for finding out about the latest craze in unit testing.
  3. For astounding photos of smokejumpers in action, visit Mike McMillan's website, www.spotfireimages.com.
  4. For un-astounding photos of goats in action, visit www.signonsandiego.com/uniontrib/20040416/news_1n16goats.html
  5. And, finally, "Nobody Ever Gets Credit for Fixing Problems that Never Happened," at web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf is a good read about making sure that prevention techniques get recognized, rewarded, and sustained.

User Comments

44 comments
Clay G's picture

I say the Best time for catching "bugs" is before they are even bugs. I think the bugs you find by reading through code are generally the "you didn't handle null" type, while I mainly see really serious and expensive bugs from misunderstood requirements and incomplete business rules. They are not usually detectable by reading code because they're about how the system works as a whole.<br/><br/>Your "goat" was okay, but from from the title I thought it might be about acting stubborn as a goat (bad rap?) in not allowing shoddy work or unanswered questions to slide past, requiring heroics later on. Because there is usually a pressure to be rushing forward, doing the next task (similar to Fred Earl's comments). Being a stickler for completeness and quality can be unpopular in the short term. And its a balance, avoiding "analysis paralysis" but not being a lemming either.

October 14, 2004 - 2:41am
Clay G's picture

I say the Best time for catching "bugs" is before they are even bugs. I think the bugs you find by reading through code are generally the "you didn't handle null" type, while I mainly see really serious and expensive bugs from misunderstood requirements and incomplete business rules. They are not usually detectable by reading code because they're about how the system works as a whole.<br/><br/>Your "goat" was okay, but from from the title I thought it might be about acting stubborn as a goat (bad rap?) in not allowing shoddy work or unanswered questions to slide past, requiring heroics later on. Because there is usually a pressure to be rushing forward, doing the next task (similar to Fred Earl's comments). Being a stickler for completeness and quality can be unpopular in the short term. And its a balance, avoiding "analysis paralysis" but not being a lemming either.

October 14, 2004 - 2:41am
Clay G's picture

I say the Best time for catching "bugs" is before they are even bugs. I think the bugs you find by reading through code are generally the "you didn't handle null" type, while I mainly see really serious and expensive bugs from misunderstood requirements and incomplete business rules. They are not usually detectable by reading code because they're about how the system works as a whole.<br/><br/>Your "goat" was okay, but from from the title I thought it might be about acting stubborn as a goat (bad rap?) in not allowing shoddy work or unanswered questions to slide past, requiring heroics later on. Because there is usually a pressure to be rushing forward, doing the next task (similar to Fred Earl's comments). Being a stickler for completeness and quality can be unpopular in the short term. And its a balance, avoiding "analysis paralysis" but not being a lemming either.

October 14, 2004 - 2:41am
Clay G's picture

I say the Best time for catching "bugs" is before they are even bugs. I think the bugs you find by reading through code are generally the "you didn't handle null" type, while I mainly see really serious and expensive bugs from misunderstood requirements and incomplete business rules. They are not usually detectable by reading code because they're about how the system works as a whole.<br/><br/>Your "goat" was okay, but from from the title I thought it might be about acting stubborn as a goat (bad rap?) in not allowing shoddy work or unanswered questions to slide past, requiring heroics later on. Because there is usually a pressure to be rushing forward, doing the next task (similar to Fred Earl's comments). Being a stickler for completeness and quality can be unpopular in the short term. And its a balance, avoiding "analysis paralysis" but not being a lemming either.

October 14, 2004 - 2:41am

Pages

About the author

Harry Robinson's picture Harry Robinson

Harry Robinson is a Software Engineer in Test for Google. He coaches teams around the company in test generation techniques. His background includes ten years at AT&T Bell Labs, three years at Hewlett-Packard, and six years at Microsoft before joining Google in 2005. While at Bell Labs, he created a model-based testing system that won the 1995 AT&T Award for Outstanding Achievement in the Area of Quality. At Microsoft, he pioneered the test generation technology behind Test Model Toolkit, which won the Microsoft Best Practice Award in 2001. He holds two patents in software test automation methods, maintains the Web site Model-based Testing, and speaks and writes frequently on software testing and automation issues.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Nov 09
Nov 09