Process + Craft = Quality

This week, I moved from a general process improvement group to a software development department, to specifically focus on code quality. The most mature tool and process I left behind was a defect tracking system. Of course, in our development department, we use that defect tracking system. In case anyone asks me what it’s for, here’s my answer.

Prevent Errors, Fix Defects, Describe Failures

There are many definitions of those terms, but since when we fix problematic code we close “defects” in the “defect tracking system”, I started with that word in the middle. Leads to these definitions:

Error: The mistake someone made. (The root cause is the earliest error in the chain.)

Defect: The wrong code (missing, extra, or incorrect).

Failure: The unacceptable behavior of the code when running.

Detect each as early as possible

Each can be detected with appropriate tools. Detect earlier to minimize cost and annoyance.

Meanwhile, do it right

How?

With tools, learning, and discussion for writing good code.

Advertisement

Two Parts Human, One Part Machine

With the enormous popularity of Google, who could resist an article in the New York Times (front page, four pages long!) about how Google Keeps Tweaking Its Search Engine? Maybe we’d learn some upcoming changes (hardly) or inner secrets (definitely not). But in among the intentionally vague references to formulas and advanced mathematics, the following caught my eye:

Mr. Singhal often doesn’t rush to fix everything he hears about, because each change can affect the rankings of many sites. “You can’t just react on the first complaint,” he says. “You let things simmer.”

So he monitors complaints on his white board, prioritizing them if they keep coming back.

Singhal is responsible for nothing less than Google’s search algorithm—surely a mixture of mathematics and magic.
The article also tells us that Google has a computerized problem-reporting system where

Any of Google’s 10,000 employees can use its “Buganizer” system to report a search problem, and about 100 times a day they do — listing Mr. Singhal as the person responsible to squash them.

So why is he prioritizing his work using… a whiteboard?

Change scenes now to Yahoo’s pragprog discussion list, where experienced developers discuss their craft. (You have to sign up to see the messages.) A few days ago someone asked for recommendations on the best tool for UML. The first answer from one of the members was:

“I’ve always found a pen and a large sheet of paper rather effective myself :)”

Software development is still largely a human activity. Planning is human. Design is human. Only some of coding gets down to the machine level.

Humans like and need simple, flexible tools that don’t hold much more than people can think about at once. With planning—in its essential activity of prioritizing—if you get more than 10-15 items, the bottom of the list never gets done. No point keeping them on the list at all. For that, even better than paper, the whiteboard comes with a great accessory: the eraser. Likewise with design: the important part is the discussion, the thinking out loud. Whiteboards go great in hallways for such work.

Yes, sooner or later there’s code, and compilers, and syntax, regression test suites and repeatable builds. For those machine activities, use computerized tools and scripted automation.

But for people, stick with the whiteboard.

Don’t Watch Your Fingers

When I talk about tools for coding, some people ask,

“How can we be free when the environment is computer-controlled?”

It’s all about the right metaphor. One of mine is woodworking.

“By definition, a jig guides your tool and a fixture guides your work.”

Thus begins Jim Stack in The Best Jigs and Fixtures for Your Workshop. And he claims the 30 best in his book. But here’s a similar example from another source, to give you the idea.

There’s no improving on the authors’ explanation:

“If you’ve ever built a picture frame you’ve experienced the frustration of trying to get all of the parts to fit perfectly. While trying to “dry-fit” and clamp the frame’s pieces together the parts often fit perfectly. But add glue, and a little clamp pressure, and the parts begin to slide apart. It can be a frustrating race against the clock to even things out before the glue begins to set.

(By the way, by Stack’s definition, this example is really a fixture, not a jig.)

If you’ve ever tried framing a picture, you may know what they’re talking about.

Equally well if you’ve ever raced to get your program to compile and run before you go home.

Yes, that picture frame looks pretty tightly constrained. But it’s not limiting my creativity as a carpenter.  It’s just holding the pieces in alignment so they don’t all fall apart. I don’t find myself thinking creatively when I have glue all over my fingers and wood stuck to the carpet.

Your tools include the IDE and the compiler. Your work is, clearly, the code.

What kinds of add-ons (“jigs”) guide your tools? What kind of fixtures can help guide your work?

Here’s the rest of that site: http://www.woodzone.com/tips.htm. Look through it and then make your own list for coding.

You don’t even have to watch your fingers.