I like to get off of the beaten path. Not too long ago, I loaded my gear and my dog into the pickup and headed out on a road trip. I'd been warned about the bad roads where I was going. I've been on some really bad roads, roads that were little more than two rutted tracks studded with rocks and choked with vegetation, so I figured I could handle what ever this trip dished out.

I kept a wary eye out for the bad roads, but I never found them, at least not on this trip. Clearly, my definition of "bad road" is different from the common parlance. As I cruised along on wide, smooth, packed gravel roads, I reflected on the way we use language and one specific way that gets us into trouble when we build software.

When we toss around adjectives in casual conversation, it usually doesn't result in multimillion dollar misunderstandings—I didn't suffer any trouble on my road trip as a result of the disconnect between my definition of "bad road" and someone else's. That's seldom the case on software projects.

Make Comparisons Explicit
Think back to a time when the marketing rep from your company reported that your customers wanted the software to be more secure. Secure compared to what—an e-commerce site? An ATM? The previous version of the software? It's all too common for people to assume that their definition of "secure" is the same as the other guy's, and that can lead to big problems.

When you hear any adjective or adjective phrase without a comparison, ask questions to calibrate your understanding:

• How would you describe the security of the current system?
• What is your benchmark for a secure system?

Understand the Underlying Need
Once you've calibrated both definitions of secure, continue to probe to understand the reasons behind the desire for security (or any other attribute):

• What aspects of the current system are secure? Which ones are not?
• If we address the specific security gaps you've identified, will that satisfy your request for a more secure system?
• What problems will go away if these security issues are fixed?
• What's the worst problem we can anticipate if we don't address specific security issues?

When I understand what's behind the request, I can consider tradeoffs and make better decisions. And I'm more likely to avoid a gap in expectations.

You can calibrate adjectives when you're giving as well as receiving information. When you're the information provider, be specific:

• The customer information screen needs to prohibit access to anyone who does not have a valid user ID and password, and specific permission to update that screen. A valid ID and password can be established only by doing x-y-z. Permission is established when our security administrator sets the permission codes for that employee.
• Our goal is to reduce the number of defects we ship by 25% compared to the number of known defects shipped in Release 2.1.4.
• Our goal is to address specific potential security breaches, a-b-c, in the next release.

Check for Mutual Understanding
Make sure your message has been interpreted the way you intended or that you've really understood another's message. Try paraphrasing—restating the other person's ideas in your own words. You can check right then and make any corrections to your understanding. Or try writing down what you believe they said, either as a requirement or as an acceptance test. You and the other person can check the written version to see if it shows you really are on the same page. If you're not, at least you'll have a chance to work toward mutual understanding before writing the code.

The gap between the "bad" road I expected and the "good" road I found myself driving on didn't mar my trip. But had I defined the road as "good" to someone else—the story may have been different. Mismatched definitions in software projects are rarely inconsequential. Whether you are sending or receiving the information, work to make sure that you and the person on the other side of the exchange walk away with the same understanding of what's expected or you may fall into an expectations gap.