Another Set of Eyes

January 28, 2007 by
Filed under: People, Process 

There are many organizations, and plenty of pockets of resistance within organizations, that don’t leverage the value of peer reviews in any form. Individuals create their work products on their own, possibly taking the time to step back and have a look at them from a different perspective or running a few tests on them, then the product is essentially tossed over the wall to the next consumer.

Even in cultures that advocate test driven development, when the author of the work product is also the author of the validation suite for that product, there are internalized assumptions that can lead to trouble. In any environment, for any work product, it should be considered mandatory for some level of review by another set of eyes.

Usually, the arguments around not reviewing work products before passing them on center around the lack of time or resources. This, though, is a rationalization that rarely stands up to scrutiny.

While formal inspections do require a significant investment in training, infrastructure, planning and implementation, numerous studies show that the payback for running this as a formal program is tremendous. The return on investment cited is usually around 10:1. Yes, even for all that pomp and circumstance, for every dollar invested in all that effort, organizations find that they save ten dollars downstream in reduced rework. This is a direct time savings, and doesn’t take into account the incredible value of reduced uncertainty of delivery, increased quality of the product, reduced risk of reliance on individuals, and improved culture where everyone gets more time to work on new features.

Any reasonable business person would gladly donate several eye teeth for an opportunity such as this. Most software teams don’t see this. Indeed, as schedule pressures increase, the value of inspections as a time saver and risk mitigator become more valuable, not less. Rushing the construction prolongs the overall effort.

Unfortunately, many just aren’t comfortable with that formal setting, some are not aware that the opportunities exist, others would suggest that it just doesn’t fit with their agile approach. A formal inspection program can be a hard pill to swallow.

That is why it is important to recognize there are other forms of medication for what ails most software teams. Formal inspections lie at one end of a broad spectrum of different peer review techniques. As we move down the inspection, we peel off layers of what many see as an onion. We pull back on the need for running a formal program and capturing the metrics, we get participants to bundle up some of the distinct responsibilities, we can eliminate the need to formally plan the effort, we can back off on the paperwork.
With that in mind, we get away from the boolean impression that we can do formal inspections or we do nothing. We can leverage the shades of gray.

While it is good to know how to apply formal inspection techniques for improving the quality of our work products, it is more important to recognize the imperatives of applying some form of peer review to improve everything we produce, and using an appreciation of risk exposure in determining how formally we should review our work.

We need to look at everything we build, including the intermediate products such as requirements or user stories, designs or prototypes, and assess the potential risk we need to mitigate. If the product is part of the core of our application, if it has been constantly hammered by nagging bugs, if it is being implemented by someone that is new to the team or using a new technology, there is value in moving further up the formality spectrum for reviewing the product. Greater effort, to be sure, but also a more exhaustive review of the product.

If we plan for a more formal review of the high risk items, which implies the conscious identification of these areas in advance, we can allocate the time and resources to do this properly. If time is not budgeted, it will never happen.

For everything else, identify how you can lighten up the effort, but never go to the extreme of building something and passing it along with no peer review whatsoever. That is assuming, of course, that you don’t enjoy wasting your time later.

Formal inspections are valuable, but more importantly we need to build a culture where it just doesn’t feel right to let anything go without another set of eyes going over our work. – JB


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Fantastic article [on change management]. We have extended our project tracking system as per our meeting [with Clarrus] earlier this year, and many of our change management issues/problems disappeared – some of them literally overnight.

    — Daniel Miller, CEO, Miller Software