A road trip provided an example of the importance of qualifying adjectives. It might not matter much in casual conversation. However, if you’re making decisions, you’d best have an objective comparison point to calibrate meaning.
I just returned from my annual winter trip, which included a visit to Chaco Canyon. I’d been warned about the bad roads. I’ve been on some bad roads. Roads where there was only a foot between the edge of the wheel and a thousand foot drop. Roads that crossed creek beds without a bridge. I figured with a four-wheel drive vehicle with plenty of clearance, we’d be ok.
As we made the turn down the unpaved road that covers the 20-miles from the highway to the archeological site, I looked at the road ahead of us: packed clay and gravel and wide enough for three cars.
I kept waiting for the road to deteriorate. It didn’t. The posted speed limit was 45 and it was easy going the whole way. There are a couple of places where the road needed to be re-graded. On the whole, the road into Chaco Canyon is a *good* road.
Let me tell you what a bad road is like. A two wheel tracks with ruts and barely enough room to get the truck between the trees. Or deep ruts with rock outcrops in the middle, waiting to snag some important bit on the bottom of your vehicle. On a bad road, you creep along in granny gear at 5 miles an hour (tops).
What does this have to do with software? It’s a great example of the disconnect that happens when we make assumptions and fail to qualify adjectives. This can get us in a world of trouble when trying to understand what someone who will use the software actually wants.
In this case I made an assumption about the adjective “bad,” used to describe a road. We use adjectives to be more descriptive. But adjectives are often subjective, and then they get us in trouble:
Think about a time someone asked for a system that was fast, or easy-to-use or secure. Chances are that your definition is different from the next guy’s. Unless the person requesting and the person delivering calibrate their understanding of what “fast,” “easy to use” or “secure” means, there’s bound to be an expectation gap.
When you hear an adjective or adjective phrase without a comparison, ask questions to calibrate meaning. One obvious question is “Compared to what?” Other probing questions might be:
- Describe a system that is “easy to use.”
- How would you know something is “easy to use”?
- What would make this software “easy to use”?
Probing questions such as these elicit more information, and often reveal useful clues about the other person’s context.
When you’re doing the talking, be specific. For example:
- The customer information screen needs to display in less than 1 second.
- That’s 1/3 faster than the current screen return of 1.5 seconds.
- 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.
Be prepared to explain why the specific requirement is important. That provides more context and may open a discussion of trade-offs.
When you calibrate subjective statements or probe for more information, you’re much more likely to build what’s desired. And when you are specific, you’re much more likely to see the result you want.
