Quality in-the-small

Summary: Quality driven dev, when dialed to 11, can quickly reduce error rates to near zero.  At least that’s the theory.


Big Bang fails too big. Frequent delivery fails more often and provides better learning opportunities. That’s a huge improvement. Quality-driven dev, which focuses agile dev on salient quality factors, can further improve dev results. 

Operational definition of “quality”

    Q(total) = f (q1, q2, … qn) 

That is… for any cycle, quality is some function of the salient quality factors in your context. 

Knowing your context, *you* are responsible for defining quality for your customers. If you want someone else to define and manage your quality, you are sinking not swimming.

If this sounds like a heavy responsibility, relax, here is a theoretical life preserver:

  • Atomize and timebox your cycles
  • Select ONE QF as the driver
  • Ignore other QFs (!)
  • Make your code change(s)
  • Run your acceptance tests for that QF

If you have concerns about potential side effects (e.g. a focus on security may have affected performance), then explore or rerun the tests for this other QF (in this example, performance).

The theory is that as cycle time approaches zero, the risk associated with ignoring secondary QFs also goes to zero.

My recommendation is to try this at home… or at least with an engaged customer.

I’d love to hear your results.


About iesavage

Oregon software quality pioneer. Writing about quality, Oregon, software, and pioneering in no particular order.
This entry was posted in Uncategorized. Bookmark the permalink.

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 )

Google photo

You are commenting using your Google 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