Talk About Quality

“Isn’t it nice to know that, when all else fails us, we have an innate decision-making tool to fall back on?”

Robert L. Glass, “Intuition’s Role in Decision Making” (IEEE Software, January/February 2008)

Yes, Glass admits, estimates that come unbidden from a manager’s subconscious seem the very opposite of quantitative or rational. But most decision-making methods have a common theme: using historical data to decide what to do next. Quantitative estimation puts everything out in the open. Rational support for a desired deadline is at least based on the facts. Intuition, at the other extreme, pulls that data, informally known as “experience”, from the subconscious. And since a good manager has experience, intuition works.

Sort of.

What’s hidden by Glass’ essay are the unstated quality standards that justify each method. Only a complete, quantitative estimate, matched by continuous measurement and adjustment, can promise high quality by the target date. Intuition, on the other hand, even coming from an experienced manager, makes quality likely, but hardly guaranteed. His successes are what keep him in his job, and his few failures are forgiven. Rightly so. He is employed to deliver good enough software, quickly, to meet modern society’s ever-growing appetite for computerized life.

So should we favor intuitive, seat-of-the-pants estimating, with its benefit of early delivery, but its cost of uncertain quality?

Digging deeper, we find that there are some very different reasons why we write software, which strongly influence how we plan our work.

1. Profit
2. Functionality
3. Beauty

Anyone who gets paid for writing commercial software must acknowledge that profit pays his or her salary. Profit leads eventually to pretty good quality, via competition. In the short run, though, we experience a lot of pressure, a lot of errors, and many customer-accepted (if sometimes societally unacceptable) failures. In that context, it seems, we should estimate quickly and intuitively, but admit that quality is expendable.

In a well-funded, non-profit organization (e.g. NASA, famed for error-free software — wholly separate from failure-free flights), software can be about complete functionality. Take as much time as needed to implement everything, perfectly. After all, when the spaceship flies past Jupiter, there’s no second chance.

Where, then, is guaranteed perfection, estimated correctly and delivered quickly? The only place we see that in life is artistic performance. A pianist plays, from memory, a piece that she only decided a few months ago to perform. An hour long, no mistakes. The event starts, and finishes, on time. The customer — the audience — rises to its feet in noisy appreciation. The enabler of perfection is seeking beauty, or doing a thing for its own sake.

Many software developers write software because it’s beautiful, fun, or spiritually rewarding. And that reason engenders the highest-quality work. A quality that delivers on time, with no costly rework. Functionality. Profit too.

Somehow, in the commercial context, that reason why we write software must be harnessed and encouraged by software managers. Otherwise, dismissing a developer’s data with an intuitive estimate is not a fall-back, but falling backwards.

I may be an exception, but if there’s one thing I enjoy, it’s buying the right tool for a specific job, when the job needs doing. It gives me an excuse to buy a new toy, as well as the pleasure of having a task go smoothly. Faithful readers may remember my first post here, Choose and Use the Right Tools, where I didn’t, and how that turned out.

Today I got a second chance, when my son decided to move his PC to the other side of his desk. With my wife’s permission, we set out to drill another hole for the computer cables. (My wife designed the desk, which is probably worth a good deal more than the PC.)

This time, when I got home from work, I was already presented with a new special-purpose hole saw. There was a little concern that it cost $20, but I reassured everyone that it was fine—this time we would use the right tool and get the job done nicely.

We got all prepared: cleared the work area, measured and marked the hole center on the bottom of the desk to ensure clearing the frame of the desk, put masking tape on top to prevent chipping, and drilled a starter hole all the way through. Came to putting the hole saw in the drill, though, and … it wouldn’t fit.

My son sped up—started thinking of all sorts of quick ways to attach it to the drill anyway.

I slowed down. I decided I would either become much more knowledgeable about hole saws in 15 minutes, or we would put the whole thing away ’til tomorrow and ask at the store. Well, I learned about what a hole saw and drill look like together, what mandrels are and what arbors look like, and finally settled on the understanding that my drill should definitely accept bits with up to a 1/2″ diameter shank. Pretty technical, huh!

All I can say is that this newfound knowledge gave me the confidence to open the drill chuck a bit larger, and then the hole saw (1 cm metric shank—do the math) did fit. We continued the job, including drilling the hole half of the way from the top, and the other half of the way from the bottom, so that the finishing cut would be in the middle of the desk thickness where it wouldn’t damage either surface. Out popped a plug of wood, just like in the picture.

What, you might wonder, does all this have to do with learning, and software development?

For years I’ve been trying to learn about regular expressions because they seemed so useful. But I never got very far until this week. I had to prepare a demonstration of integrating a source code editor (my current favorite—Source Insight) with some XML-modified output from PC-Lint. Well, it took me more than a hole saw’s 15 minutes, but a lot less than “years”. About an hour-and-a-half and I had—rather suddenly, it seemed—taken control of regular expressions for myself.

What made the difference? I had a specific task to do. I was no longer focused on the learning, but, as with the hole saw, on the necessity of the task at hand. A real task, whose result I had promised to someone else. With that promise, the learning just came by itself.