Fightin' Words

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 and development methodologies promised great increases in our productivity and the quality of our work. But the payoff didn't match the hype, so the term "methodology" fell out of favor. Some people carefully distinguished overbearing, big-M Methodology from thoughtfully applied, small-m methodology, a distinction that is problematic when communicating verbally. But now methodology is back, with the preceding word "agile" to distinguish it from the old, big-M Methodologies. I guess it's okay to use the "M" word again in polite company.

You might have good reasons for avoiding some key words in your environment. Some organizations reserve the title "engineer" for individuals who hold a professional license in, say, electrical or mechanical engineering. Thus, referring to a software developer as a "software engineer" might be viewed as an affront (or an oxymoron) by licensed hardware engineers.

Rather than avoiding certain overloaded, hot-button words, make your definitions clear and call objects and activities what they are. A little education goes a long way toward improving the interpersonal communications that contribute so much to software success-or failure.