The names we give to things can have a powerful influence on how we think about them and also on how we get others to think about them. In this week's column, tester, test manager, and consultant Fiona Charles examines names we have given to two essential roles in software development and explains why at least one of them is both inaccurate and a problem for testers.
What's in a name? That which we call a rose
By any other name would smell as sweet.
(William Shakespeare. Romeo and Juliet. ACT II Scene 2)
What do you call your professional role? Are you a tester? A Quality Analyst? Quality Control Specialist? Quality Engineer? (These "Q" titles always seem to be capitalized.)
Does the name matter?
It's true, as Shakespeare said, that a rose would still look and smell just the same, even if we suddenly started calling it "skunk cabbage." But changing the name would influence how people perceived the plant. Those who'd never encountered a rose would be much less attracted to the idea of something called skunk cabbage (though skunk cabbage happens to be quite an interesting garden plant in its own right.) If they wanted fragrant flowers, they'd be less inclined to buy skunk cabbage than roses.
What if we turned this around? If we decided that skunk cabbage should be called roses, I think we could predict the result. Their essential nature wouldn't change, and they'd still smell skunky-not at all like roses. But in this case the unwary public who wanted nice-smelling flowers could be enticed into buying a plant that doesn't smell pretty.
So there is something in a name. In fact, naming is a very powerful act.
Marketing professionals know this, of course. So do managers and others who want to change perceptions in their organizations. When an organization sees testers as something like "the people who walk behind the programming elephants with shovels," then it's understandable if some people want to change that perception. So, they change the name, expecting perceptions to follow.
Jerry Weinberg calls this "name magic," a term from cultural anthropology. Here's a riddle he uses to illuminate name magic.
Q: If a dog has four legs and you call its tail a leg, how many legs does the dog have?
A: Four, of course. Calling a tail a leg doesn't magically make it a leg.
The power of name magic is that names carry associations that resonate in our minds. When we give a thing a name, we imply all the attributes of that name. If it's an inflated name, like "engineer," we are attempting to inflate the role. But calling a tester a Quality Engineer doesn't make the tester a person who engineers quality into software. No tester can do that.
In my plants example, knowledgeable plant-lovers would continue buying and planting roses for their sunny gardens and skunk cabbage for their bog gardens, whatever they were called. That's because adopting marketing tactics and changing a role name will only influence the perceptions of those unfamiliar with the actuality of that role. If your organization's culture causes the programmers to see testers as skunk cabbage, then testers are still going to be skunk cabbage even when they're called roses-or Quality Engineers.
Name magic doesn't make the problem disappear. So why not call yourself a tester and address the problem directly? That's harder than attempting name magic, of course.
How can we do it? Maybe we'll never really get anywhere until we reverse an act of name magic that happened early in our industry's history.
We testers have an honorable calling. We have specialized skills and a mindset that is unique-and uniquely valuable-on software projects. But many programmers and managers don't believe we can do anything the programmers can't do just as well. For these people, programming is the highest calling, and the techies who write code are the only essential resources in software development.
I think one reason for this is