Laconic Look-see into Quality

How do we recognize quality? How do we know what's good?

When experiencing the not-yet-experienced, we have an immediate left-brain, intuitive reaction. A split second later, our right brain serializes and categorizes our experience; to reconcile our experience into comfortable intellectual constructions.

Masterfully developed by Robert Pirsig in his books Zen and the Art of Motorcycle Maintenancence and Lila, Quality or Value cannot be defined because they empirically precede intellectual constructions.

Pirsig further defines the concept of Dynamic Quality as "the pre-intellectual cutting edge of reality" -- because Dynamic Quality is recognized before one can think about it.

Quality is a direct experience independent of and prior to intellectual abstractions.
--Robert M. Pirsig

For Pirsig, the word "good" functions just as well as a noun as an adjective; reasoning that our concept of Quality is a philosophical measurement of goodness.

One school of thought is that good is quantifiable, even if we can't measure it scientifically. This is perhaps the antithesis to what Pirsig believed. Yet, it is a commonly-held assumption about quality that we often encounter in the software industry.

Do we owe this short-sighted conception of quality to pointy-headed Managers who salivate on metrics dashboards? Or, do we need to re-examine our own definitions of quality?

What Does Quality Mean? is a brief primer by Mark Levison that includes what others have said about software quality. In an instructive rant called Killing Quality, Mark Bria makes a valuable observation about a big pothole in commonly held assumptions about software quality

"Quality" should be used as a measure of functional/aesthetic utility to our consumer, and not as a measure of defects. Really, it should just be assumed that defects are generally absent. This should just be implied in what it means to be a Professional.

Mark's implication is that we've tainted Quality in the software world by assuming Quality means lack of defects, rather than presence of value.

For Camp Coiner (right), the Home of Zero Defects, zero defects might be a matter of life and death - an essential quality definition.

Zero defects in software is the price of entry -- but not a particularly meaningful evaluation of quality.

Perhaps the easiest way to recognize dynamic quality, or lack there-of, is to observe an experienced user struggle with a counter-intuitive user interface.

While not always successful, most of us try to follow the Occam's Razor approach to user interfaces. The Occam's Razor school teaches us to shave off those widgets, do-hickies, and ajax-i-fied eye-candy that are not really needed to explain how to arrive at the desired function. Following Occam's Razor, there is less chance of introducing inconsistencies, ambiguities, redundancies and unexpected behavior.

An example that will help us experience the spectrum of the recognition of quality, or value, is to compare the two popular agile tracking products -- the commercial product, Name Withheld, and the open source product, XPlanner.

XPlanner has a plain vanilla interface with classic HTML controls and forms with full post-backs. Not pretty. But if you've used it, you remember that you rarely complained because it fulfilled your needs. Simple and intuitive. Who would not would rate this product as a good value or good quality?

Also on the quality spectrum, is the organizationally popular Name Withheld. My initial impression, and ongoing experience using Name Withheld, is frustration. Using this product is like driving in a strange city where the streets are very tidy and the building's are quite attractive, but I have to circle every block 2-3 times before finding my destination. From a user experience viewpoint, who would rate this product as a good value or good quality?

Here's hoping that Version Two of Name Withheld will be more intuitive than Version One of Name Withheld.
--Bob MacNeal

We avoided the sticky wicket - How do we evaluate quality in software? In a subsequent post, we'll do this by assuming very practical constraints - we'll pretend a venture capital firm is paying us a retainer for due diligence on a software product. What would be the range of things we might examine? How would we evaluate them?

Beginner's Mind, Dumb Luck & Agility

Even mindful software developers become jaded and closed-minded.

We sink into complacency. We find ourselves spinning in the tire tracks of familiarity and comfort. We tell our business sponsors, "That's just the way we do it”. We harbor habits-of-mind and insecurities that we hold onto because of ease and familiarity.

Beginner's Mind, or Shoshin, means cultivating an attitude of openness and eagerness. It means establishing an innocence of preconceptions in one's approach to something.

Beginner's mind is the mind of child; full of curiosity, wonder, and amazement.

Can we approach our day-to-day tasks in such a way? Can we look at all of the aspects of our professional lives with this mind -- open to see what there is to see?

We can. But it requires sustained practice, patience, and steady vigilance.

In Zen Mind, Beginner's Mind, Shunryu Suzuki says,

In the beginner's mind there are many possibilities, in the expert's there are few.

Beginner's Mind and Dumb Luck are two sides of a coin -- a coin that every developer needs nestled in his pocket protector. Beginner's Mind is a mind that's not already made up. It's a mind in investigation mode -- curious and open to whatever happens.

A Beginner's Mind is ready to embrace Dumb Luck.

Friends, and master potters, Randy Johnston and Jan McKeachie-Johnston have a term for Dumb Luck that I prefer, calling it The Nourishable Accident. Working with a pliable material like clay, potters have to relax their expectations. Randy and Jan are forever mindful of opportunities in accidents. That is what makes their work sought after.

We know that agile teams embrace change. As practical agilists, perhaps our mantra should be to

Mine every change for its dumb luck.

That is, to see change as a child would: with Beginner's mind.

Go now grasshopper. Bound off to Iteration Planning with Beginner's Mind:

• Recognize Change as Opportunity
• Nourish the Accident
• Mine the Dumb Luck

Pavlov's Programmers

A business development manager posted the question

Programmer, Developer, Engineer --

What is the difference between them?

Responders expounded on the minutiae of perceived distinctions.

One person, likely an Engineer, portrayed a Programmer as some kind of Pavlovian dog that, given the right stimulus (e.g., excruciatingly detailed requirements), was capable of producing the desired result (e.g., a minimally functional application).

These titles are interchangeable. And, more importantly, they’re increasingly irrelevant.

Glib Response

• A humble person says he's a Programmer or a Developer.
  
• An insecure person says he's an Engineer or an Architect.

Salient Point

Successful software teams are self-organizing and behave like start-ups. Enlightened teams eschew titles; recognizing that teams are more productive, and more agile, when members wear multiple hats.

For those more secure with a highfalutin title, I urge you to accept that as software professionals in 2009, we are

The ditch diggers of the new millennium

You may quote me on that.

Why Design-Build?

In Architects & Agile Like Zen Monks & Cell Phones, I questioned the relevancy of software architects in agile.

This morning I recalled two additions we'd made to our home. Both efforts were done by a superb craftsman who, in both instances, urged us not to engage an architect.

Both projects were completed on time, within budget, and, to our ongoing satisfaction, the results are functionally and aesthetically pleasing.

The trend toward agility in the software business is mirrored by the construction industry which has been evolving for more than a decade toward a Design-Build (DB) approach. In their version of DB, one contracting firm does the design and the construction; in contrast to Design-Bid-Build, or DBB, where one firm does the design (architecture) and other firms (construction) bid on the design specification to do the work.

A 1999 study by the Project Delivery Institute at Penn State found that DB beats DBB in delivery speed and in delivering at a lower cost. See the graphs above and right.

Is an additional advantage of DB for the construction industry

the ability to change on the fly?

In days of yore before agile, I questioned the wisdom of separating designing and building into buttoned-up packages that marched in succession. I knew that

we learned things as we built

and that

we adjusted accordingly

This summer my son will participate kiln-building course where students will design and build a wood-fired kiln. He’s an architecture student who is also passionate about functional pottery.

This is his first opportunity to build a structure that will provide decades of utility to others. I wondered if it would be his last opportunity to build a structure as opposed to conceptualizing a structure.

A side-benefit of agile is the organizationally-imposed distinction between architect and developer is blurred, if not irrelevant. In well-oiled agile teams, people wear many hats. As such, successful teams behave like start-ups (i.e., from necessity, they're too small to segment specialties, so everyone does whatever needs to be done).

Design-build is personally satisfying, even if my design contribution is only to confirm what my more conceptually gifted team-mate, was thinking.