Fightin' Words

Do you ever shy away from using terms your coworkers or organization may have come to regard negatively—perhaps words like "process" or "CMM" or "inspections"? Why is it not okay to call a spade a spade—or a process a process—for fear of scaring team members who don't understand or value contemporary software engineering practices? In this week's column, Karl Wiegers explains why he doesn't play those games (and how he gets away with it).

A client who invited me to present a seminar on requirements engineering said his (well-known and world-class) company was struggling with requirements prioritization. I suggested a definitive prioritization technique called Quality Function Deployment, or QFD. "Oh, no," he replied, "we can't say 'QFD' around here." The mere notion of QFD repelled his team members for some reason, and he wanted me to come up with a more palatable-sounding prioritization technique.

How can we regard software development as an engineering profession if we are afraid to use certain terms? Why is it not okay to call a spade a spade-or a process a process-for fear of scaring team members who don't understand or value contemporary software engineering practices? Several of my clients have warned me not to use the "P" word (process) at their companies, because software process has an evil connotation there. "Instead of talking about process, we just call it 'solid engineering,'" they say. I've also been cautioned against mentioning the Capability Maturity Model because some people in the organization don't understand it and think it's "a bunch of crap."

I don't play those games. Instead of taking the unprofessional action of shying away from sensitive words, I'll educate each audience about what I mean when I use a certain term. We might not all agree on the merits of the concepts we discuss. However, I'm not going to dance around language issues because a few people had a bad experience with an inappropriate software process during their impressionable years.

Certain hot-button software terms can make hackles rise instantly. But there is often a way to keep the discussion moving. For example, when I first became a manager, I had to give a status report about my group's activities to a group of senior managers. During that presentation, I stated that my software group would no longer do any work without a written requirements specification. One rather whiny manager protested, "I'm not sure your definition of 'specification' is the same as mine." I had two responses for him. First I said, "Then let's use mine." Then I told him what I considered a requirements specification to be: an agreed-upon description of the user needs and the new system's capabilities and characteristics, written in sufficient detail to permit development to proceed at an acceptable level of risk. Mollified, he responded with, "Okay." A brief moment of explanation defused this manager's initial resistance to what he perceived as an obstacle to getting work done.

Sometimes a person's background influences an interpretation of a term that is different from how it is used in the software business. A quality manager with a manufacturing background once objected when I described how my team was applying inspections effectively. She interpreted "inspection" as the outdated quality concept of examining a finished product for defects (you've all seen "Inspected by Number 7" tags in new clothing). After I explained that a software inspection is an in-process manual examination of a work product intended to uncover problems early and cheaply, she understood why we were enthusiastic about inspections.

Some developers have had unrewarding experiences working with consultants who used certain terms as a kind of high priest's mystical incantation. If you took a terrible class or read a lousy book on, say, risk management, you might react warily any time you hear the phrase "risk management." The emotional experiences you accumulate during your projects can make it hard to be objective and open when you encounter such touchy terms in the future.

Once upon a time, "methodology" was an exciting new term in software engineering. Innovative design

About the author

Karl E. Wiegers's picture Karl E. Wiegers

Karl Wiegers, Ph.D., is the Principal Consultant at Process Impact in Portland, Oregon, and the author of Software Requirements (Microsoft Press, 1999) and Creating a Software Engineering Culture (Dorset House, 1996). You can reach him at You can find more than 35 of Karl's articles at

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Apr 29
Apr 29
May 04
Jun 01