Home > technical > Capers And Salmon

Capers And Salmon

I like capers with my salmon. In general, I also like the work of long time software quality guru Capers Jones. In this Dr. Dobb’s article, “Do You Inspect?”, the caped one extols the virtues of formal inspection. He (rightly) states that formal, Fagan type, inspections can catch defects early in the product development process – before they bury and camouflage themselves deep inside the product until they spring forth way downstream in the customer’s hands. (I hate when that happens!)

The pair of figures below (snipped from the article) graphically show what Capers means. Note that the timeline implies a long, sequential, one-shot, waterfall development process (D’oh!).

That’s all well and dandy, but as usual with mechanistic, waterfall-oriented thinking, the human aspects of doing formal inspections “wrong” aren’t addressed. Because formal inspections are labor-intensive (read as costly), doing artifact and code inspections “wrong” causes internal team strife, late delivery, and unnecessary budget drain. (I hate when that happens!)

An agile-oriented alternative to boring and morale busting “Fagan-inspections-done-wrong” is shown below. The short, incremental delivery time frames get the product into the hands of internal and external non-developers early and often. As the system grows in functionality and value, users and independent testers can bang on the system, acquire knowledge/experience/insight, and expose bugs before they intertwine themselves deep into the organs of the product. Working hands-on with a product is more exhilarating and motivating than paging through documents and power points in zombie or contentious meetings, no?

Of course, it doesn’t have to be all or nothing. A hybrid approach can be embraced: “targeted, lightweight inspections plus incremental deliveries with hands-on usage”.

  1. December 27, 2011 at 1:19 am

    I certainly agree that an agile method should be used wherever possible, but that doesn’t mean it can always be used, or is always the most appropriate. There are still a lot of situations where the client basically can’t, or won’t, be involved until near the end of development (in particular if there is a physical device involved).

    Nonetheless, I also don’t see a problem with doing Fagan like inspection in an agile method. Even here you still have mini-processes inside each iteration (and possibly overlapping). You still have the opportunity to look at requirements before they reach coding, or to test the code before it reaches the client.

    • December 27, 2011 at 4:52 am

      Fair enough Mortoray.

      I’m going to go out on a limb and say that an incremental, iterative process is almost always appropriate and should almost always be used – regardless of whether it’s officially considered “agile”. When hardware is involved, a software emulator can be written, integrated, and delivered to customers to bang on. Even if the “real” customer won’t be available till near the end of the project, an internal group or person can be delegated as a customer surrogate.

      I don’t see a problem with doing formal inspections in any methodology either – provided they’re “done right” and, thus, the investment is recouped. I suspect that because of the social challenges that need to be overcome to do them “right”, most of them are not done right.

  2. December 28, 2011 at 3:46 pm

    I am a proponent of inspections but experience has taught me that they can become a bureaucratic waste of time. I have found that ADDING two things to formal inspections can add significant value AND enhance compatibility with agile. First, put together a small “software artifacts standards committee” with your top developers, business analysts and testers and get them to set the criteria for inspections or, in other words, “What are the inspectors looking for?” A checklist works well. This group should meet regularly to consider updates based on newly identified helpful or hurtful patterns. Second, Two tiers of formal inspection should be implemented – the committee approach specified by Jones and a peer-to-peer approach that completes the inspection checklist without going to the full committee. The standards committee decides on a policy for which artifacts go to which level of inspection based on the ROI.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: