Talk About Quality

A new project is ramping up and needs more resources. Another project is winding down — maybe it can do with less.

Let’s move some people from one team to the other

What’s wrong with this common resource allocation decision? It’s not the decision. Moving resources to the project that needs them makes sense. What’s wrong is the words, which hide a false assumption.

Here, “team” means location. Move people from one place to another. Like conductors putting people on a train: the “teams” are two train stations. One called “Project A Station” and the other one, “Project B Station”.

But teams are not train stations. A team is not the room it sits in, or its box on the org chart. A team is the particular combination of people — their skills and personalities — and their shared experience. They know their project or product best right now, and equally important, they know each other and the special role each person fills. Reassigning people from one team to another is more than moving a person. It is actually dismantling the first team, and disturbing the second. The movement of people based on the train-station model of teams leads to a contradiction: both teams — origin and destination — cease to exist.

If we must model people and treat them as resources, a better model is a hand at cards. The managers are the players and partners; the game is getting more projects completed. There’s a fixed deck — the “human resources” of the company. Some cards may be similar in strength or level, but every card is unique.

The value of your hand is based entirely on the combination of cards you’re holding right now. If you or your partners need a stronger hand, everyone knows that some cards will have to be exchanged. Put down 2, pick up 2. I pick up what you put down. Resources. Cards. I know this doesn’t sound any better to workers than “counting heads”, but it is. Because every card player thinks twice before putting down a good card, and prefers to take over an entire good hand if they can.

A co-worker forwarded me this article ”5 Reasons for Software Developers to Do Code Reviews (Even If You Think They’re a Waste of Time)” which certainly sounded promising. Even when I don’t think code reviews are a waste of time. But as I read through it, it became clear that more is less. The article says too much, and detracts from its own message.

1. Developers know their code will be evaluated, so they work harder. “The most useful thing about a code review is the fact that the coder knows that someone is going to review the code,” says Oliver Cole, president of OC Systems and also lead for the open-source Eclipse Test and Performance Tools Platform project.

Work hard because you enjoy it. And of course your code will be evaluated, but not primarily by code review. Rather, the main user of your code is the “next developer”—possibly someone on your team, or even you yourself a few months later. That’s where the evaluation happens.

 2. It improves a developer’s own programming skills.
In your heart, you might not care that much about the success of this particular software project. But most programmers want to improve their personal skills, and that means learning from other people.

If you don’t care about the success of the project, code review won’t help.

3. It’s an opportunity for mentoring, so the programmers you work with get smarter (and thus, more fun to hang around with).” [...] While the intention [to mentor individuals] is generally well meaning, it can often lead to individual discomfort and perceived or actual criticism. In these cases, the greatest opportunity for mentoring usually exists in the context of small collaborative teams working together to realize goals and not in a code review.”

Criticism is not bad, it is essential. It is not personal, but professional. And of course, the smaller the meetings (down to even just 2 people — reviewer and author), the better.

4. It creates consistency and a culture of quality across the project. [...] Developers are quick to complain about being judged on the wrong metrics, but, says Gary Heusner, client partner at custom software developer Geneca, “We have to change the rules to allow for quality and efficient development to be valued over making milestones that are really yardsticks of process more than milestone of value delivered.” Code reviews are a big part of that.

Code reviews are simply part of good software development.  When management, together with the team, track value delivered, that is a big part of creating a culture of quality. Only when the environment is right can code reviews have a chance of being effective.

5. It encourages team bonding. “People think code review is just about finding bugs, but it brings people together, says Smartbear’s Jason Cohen. Often, he says, it can deliver far more than expected.

“Success stories happen very often when performing code reviews,” says Dave Katauskas, senior architect at Geneca. “But the best success story is the pattern that develops once a team has gelled. The longer you’re into a project, the better quality code is created. This is all due to the code review process and governance that occurred up stream in the beginning of the project.”

I had to read this one a few times. Right answer for wrong reasons. I will not credit code review where credit is not due. Even the writer with the “success story” realizes the true origin of the success is the gelled team.

But still, I had to click on the Jason Cohen link to see why code review “brings people together”. Go ahead—click below on “Lightweight Code Review Episode 5: Team Building for the Cold, Dark, and Alone”. But first, get ready to read it right: code review doesn’t create good teams. Rather, good teams benefit from code review. OK, now click.

Lightweight Code Review Episode 5: Team Building for the Cold, Dark, and Alone

“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.

Rarely does a topic stir up more controversy than code review. And global warming doesn’t either, though perhaps it should.

I was grateful for the opportunity to see Al Gore’s very slick hour-and-a-half documentary, An Inconvenient Truth, about global warming and carbon emissions. Whatever you may think of Gore, blatant promos for Apple laptops, or computer-generated tear-jerker sequences of drowning polar bears, it is worth seeing as a thought-provoking presentation.

Remember to think.

Some of the questions I was left with after recovering from the “mild thematic elements” (yes, that’s what gave it a PG rating) are:

• What does “carbon neutral” mean? And “carbon offset”?
• Are carbon subtraction programs working as planned?
• Is carbon emission reduction going to save us from a global warming disaster?

Nothing is as simple as it seems.

Carbon neutral refers to “calculating your total climate-damaging carbon emissions, reducing them where possible, and then balancing your remaining emissions, often by purchasing a carbon offset. (Related term: carbon negative.) “

(If anyone has a more formal source than a word popularity article, let me know.)

Hmm. What about “carbon negative”? It’s easy to get distracted on the web, but the only real answer is planting more trees. (All that stuff about buying carbon dioxide emission reductions from other organizations is nonsense — not that it’s not helpful, but it’s not taking carbon out of the atmosphere – just paying for someone else to put less in rather than reducing one’s own emissions.) A bit disturbing to find, then, that even Friends of the Earth has raised concerns about how carbon-reduction tree planting is being carried out. Humbling too—one more example of how we never quite know the effects of one man-made intervention carried out to mitigate another.

Finally, if one can entertain the thought that world climate change might be a bit more complicated than a 100-minute movie, there’s short, medium, and long reading to be found at JunkScience.com.

What seems to me, though, is that the reductions—that are currently fashionable to call carbon emission reductions—are probably good for “old-fashioned” (1960’s) reasons: reduce landfill, keep air clean for breathing, improve personal health through exercise, and increase spiritual health by slowing down.

Will all this get lost in the Carbon Rush?

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.