Practical Programmer: An Embarrassing, Yet Rewarding, Ending to a Previous Column

• "The hurrier I go, the behinder I get"—old folk saying

This is an embarrassing column to write.

It’s a sequel to my now-long-ago December 1998 column, in which I took the position that schedule pressure was the undoing of the software world, and that no amount of classic software engineering—including the Software Engineering Institute (SEI) Capability Maturity Model (CMM)—had the power to undo that. That column resulted from my consulting visit to a company where all of that seemed, at first visit, to be true.

Well, here’s why this is an embarrassing column to write. I’ve since made a second visit to that company—a follow-up to the recommendations I made on my first visit—and what seemed so obvious to me when I wrote that first column now seems considerably less obvious. Let me explain.

First, I’ll give you a brief reminder of that first column’s contents. I prepared for my consulting visit by studying the CMM and the SEI’s parallel People Capability Maturity Model (PCMM), and some technological concepts (from my own books, Building Quality Software and An ISO 9000 Approach to Building Quality Software). I did this because I figured if I refreshed my memory on some of the best thinking about software process, software people, and software technology, I would then be prepared for whatever problems the company for which I was to consult had.

But, as I said in the first column, "Boy, was I wrong." The problem the organization had was a simple yet profound one—schedule pressure. "Choking, confining, impossible schedule," I had said. The folks already "knew all about how to do good design, and how to write good code, and how to do appropriate testing, including regression testing, and how to allow people to take responsibility for the work they did. They knew all that stuff, in spades. The problem was, they weren’t being allowed to do it." All my carefully prepared studying "wouldn’t help a whit," I concluded.

Time has passed since that first visit. The second visit has occurred, and I now know what happened as the result of that first visit—things are not quite what they seemed the first time around.

One of the pervasive complaints during the first consulting visit was that no one was taking responsibility for the organization’s code.

First of all, let me tell you about a few of the recommendations I made after that first visit, at least the ones relevant to this column. I recommended some organizational changes be made, primarily to put a stronger focus on software process, and to allow software management to be in a stronger position to say "no" to unreasonable schedule pressure. I recommended the developers institute better error removal processes, especially the use of inspections. I recommended that life cycle processes be instituted and designed to improve the quality of systems analysis and design.

Based on my beliefs after that first visit, as you might imagine, I didn’t have a whole lot of confidence those recommendations were going to address the real problem—oppressive schedules. But what was I to do? The schedule pressure was coming from everywhere, an amorphous enemy difficult to identify, much less fight.

Enough preliminaries. It’s time to get to the real point of this column. During the second visit, I learned an astonishing thing. I found almost all of the serious concerns of the previous visit had been resolved, and that there had been profound and successful changes in this previously troubled organization. I found people saying things like "we hit our schedule dates; we had not been coming close before," and "there was only a tiny number of errors found during integration test," and "the product became stabilized; that gave everyone confidence they didn’t have before." Someone even said "the new product went ‘smooth as glass’," a perhaps unintended pun on my name that gave me a particular sense of pleasure. (This column is about personal embarrassment, as I said at the outset, but it’s also about an experience that, in the end, was extremely rewarding.)

What on earth had happened? As it turns out, the answer is fairly simple. Two kinds of recommendations had led to those "profound and successful" changes. The ones about instituting better process. And, more specifically, the one about instituting inspections. Here’s what the company in question had done to turn things around so dramatically: it named a particularly capable and well-motivated software developer to be a sort of process guru, and armed him with the power to make things happen. He established milestones and tasks corresponding to my recommendations (defined, as you might imagine, using some of the best software engineering and SEI CMM practices). Those milestones and tasks were made as sacred as the achievement of schedule. One of those milestone/task sets was the use of software inspections.

Slowly but surely, the organization turned things around. It began to take control of its software process. It began to renew its faith in its own ability to build a good product. It began to do the things it had known all along would lead to success. How did I know those things had happened? I was told on the second visit the fact inspections that were instituted had resulted in a dramatic reduction in the number of software errors. But this didn’t happen because the inspections flushed out errors galore. To the contrary, the programmers—knowing there were going to be inspections—took responsibility for their own code and began finding and removing most of their errors before the inspection even took place. It was a classic case of a group of people retaking control of their own destiny.

It’s important to point out once more that the organization in question had capable, knowledgeable software developers, whose problem had not been the inability to do good work, but rather the knuckling under to unreasonable schedule demands. One of the pervasive complaints during the first consulting visit was that no one was taking responsibility for the organization’s code. "There is no code ownership," many technologists had told me. Now all of that had changed.

So what’s so embarrassing, you ask? At the time I wrote the initial column, I swore off all that process stuff and people stuff and technology stuff as being simply too little to help the schedule-plagued organization in question. But what I now know, after my second visit, is that things just aren’t that simple. I now realize process, people, and technology don’t directly attack the problem of schedule excess, but if used properly, they can attack the problem in more subtle ways. An organization that takes control of its process, I now understand, can take control of its destiny. And that’s a pretty powerful thought—and a nice bottom line to this column.

It’s important to add a piece of reality at this point. For all the good things that happened between the first and second consulting visits, the improvements were beginning to turn bad again. The schedule pressure did not abate because of the changes the organization had made, it was just coping better. But something bad had happened just before the second visit, one whose effect had not yet been absorbed.

The need for key people in certain development slots had caused the organization to eliminate its process group and put the process guru back into a development role. Process improvements were quickly beginning to dissolve. It didn’t matter that the changes had been astonishingly successful; that old bug-a-boo schedule pressure had struck again, in a whole new way (almost like a bacteria that evolves into a form better capable of resisting the antibiotics threatening to eliminate it).

So here’s a second bottom line to this column. Vigilance against the evil enemy "schedule oppression" must be ongoing. If you rest on your laurels after your first round of success, you are going to be in trouble all over again.

Back to Top