Talk About Quality

It’s pretty well known that there are three ways to improve software quality: improve process, improve methods, and improve tools. But these are the generic concepts — applicable to any software development effort. Today’s topic is more specific and closer to home. Product quality.

Isn’t it obvious? The software product is the running software, and product quality is how well it meets its requirements. Simply put — does it do what people expect it to do, and not crash or lose data?

But organizations which release software focusing only on that one aspect of product quality are often unpleasantly surprised by inconsistency. They are doing all the right things — following a good process, using good methods and tools, and regularly reviewing all those to see what can be improved. Yet sometimes the product is better, sometimes worse. Why?

External product quality — in software, that’s how well the software serves its users when it’s running, is not enough. There’s also internal quality. The readability of the codebase. Code that’s well-written — easy to understand quickly — is easier to maintain. Fewer programmer errors, and fewer schedule slips. We can add to that clear and organized debug output, which avoids false positives, and gives an accurate record of when the running software seemed to be fine, but was really operating on the edge — just barely recovering from failures.

But there’s another part of the product that’s often overlooked. Overlooked when reorganizing teams, or just when parceling out the daily assignments from multiple projects. The developers. If you take a single iteration of a software product, with development at its best, you’ll apply best process, methods, and tools to put out the next version of the software, and maybe even have codebase improvement (cleanup, refactoring) on the list too. Get to release and you deliver good running software, more maintainable code and … the new state of the team that developed it.

The team members may have learned new methods or technologies. Or just how to avoid pitfalls from the past. Equally important, that particular team learned how to work together — not in general, but specifically in today’s process, methods & tools, and codebase. And with each other. This third part of the product cannot be ignored or thrown away, just as nobody would think to delete a code branch delivered to the customer, or switch out a working library in mid-project.

Looking further at this third component of the product — the team that delivered it — we see clearly that those quality improvement concepts of process, methods, and tools do not exist in a vacuum. They are not just abstract ideas. Rather, they exist in the team members who develop a product, and are unified by teamwork — which means this team learning to work together with these people on this product.

So when you think of product quality improvement, plan to improve all of these:

1. How the product works
2. How the codebase looks
3. How the team works

And at the end of an iteration, make sure to review and protect all three. That’s the guarantee that the next version of the product will be even better.

I’ve often thought about the advantage that athletes and musicians have over software developers: time to practice—lots of it. Most time is spent in exercises and rehearsals, to produce the best peformance.

In software, everyone spends most of the time producing, with a bit of “time off” for learning new technologies. No wonder perfection seems so far off.

A friend pointed out that Dave Thomas has proposed CodeKata as a way of doing that practice. I read it, and while the ideas look good, I felt there was something missing. The “katas” (formal patterns in karate, and here, in design and coding) seemed somehow schoolwork-like and disconnected from real work. I could only imagine myself “practicing” on assignments where I needed the result, even if for something trivial like importing a bunch of e-mails into SharePoint (more about that another time).

I don’t have an answer today, but the question is much bigger than just finding time to practice in software development. So instead, have a look at these posts and presentations where people are discussing the issue, and see what you think.

Level 5 means never having to say you’re sorry (Jeff Atwood)

Big Macs vs. The Naked Chef (Joel Spolsky)

No Best Practices (James Bach)

Herding Racehorses and Racing Sheep (.ppt) (The Pragmatic Programmer)

Competence is a Habit (.ppt) (David Leach)

Here’s Ron Porter commenting on that 30-to-1 ratio of productivity we hear about. He talks about the top performers bringing the others up to speed. That’s not a way things work — it’s the only way.

In high school I was always on the “B” team in soccer. (Back then I was a 5 out of 30 at soccer.) My best days were when they mixed us with the “A” team — our defense with their forwards and goalie vs. their defense with our offense and goalie. Playing defense with an “A” team around me made me play better.

There are two reasons to try to make the “A” team; together they offer an opportunity for everyone. Either you are really good so you get on the “A” team, or you want to be good so you need to get on the (bottom of the) “A” team so you’ll improve.

Then Daniel Read asked how Ron mentored welders. (That’s what Ron was doing before he was programming, and perhaps before he started building boats.) Ron gave a 3-step program:

1. Stand up to superiors
2. Be willing to suffer ridicule
3. Keep records of everything

That’s my paraphrase — read how he said it: How to mentor a welder.

Ron, you’ve got it exactly right. I can assure you that it is “directly transferable to … other kinds of jobs.” Certainly not just programming. I sometimes think that programming (now called “software development”) is the only profession that thinks it’s so, so different. Yes software is different, but people in it are not.

About whether mentoring works like this everywhere: of course it does. It’s simply called “how people learn”. I wrote about it here. But don’t read me. Read Ivan Illich’s Deschooling Society.

When I’m not reading or working, I’m learning to roller blade. A pair of skates, a video here, a website there, and some practice. Gets me to about 1 out of 30. Apply Ron’s rule #2 though, and I go out to the park where all those kids skate circles around me. They’re all 10-out-of-30 going on 20-out-of-30 skill-wise. I watch them and even ask them questions. They’re fascinated for a moment that an adult might ask a kid how to do something. But they get over it quickly — acting like natural mentors. Which they are. And how about that — now I can actually skate around the neighborhood.

Mentoring is no mystery. It is kids’ stuff.

I’m still thinking about the question “What is software like?” which I tried to deal with last week in Not Like Anything You’ve Ever Seen. Today’s thought: pool. Not the swimming kind, but the kind with the pool table, sticks, and balls. Watch a professional play and you’ll see what differentiates serious pool players from the rest of us:

Position play: This is the act of hitting the cue ball with the necessary speed (and spin, if needed) to get the cue ball to end up someplace on the table where you’ll be able to get the next ball in easily. In short, it’s the strategy of thinking ahead and setting up your next shot.

(From lesson 2 of SoYouWanna learn to shoot pool?)

When writing code, it’s a whole new game if you write code not just to run, but to make it exactly ready for yourself (or someone else) to add the next feature or change.