Imagine you tell your non-tech-savvy client about a new model in computing whereby shared resources, software, and information are provided to computers and other devices on-demand.
"What?", he probably says.
Now imagine instead that you call it cloud computing, and explain that software is served outside your walls like a public utility.
Does it make a difference? Yeah, probably.
Part of what's going on here is something called cognitive fluency, the idea that things that are easier to think about seem to be more true, intelligent, and likeable. As the theory goes, this mental quirk is actually a design feature crafted from our evolutionary past. Drake Bennett in an article in the Boston Globe writes:
Unfamiliar things - whether they were large woolly animals, plants we were thinking of eating, or fellow human beings - needed to be carefully evaluated to determine whether they were friend or foe. Familiar objects were those we’d already passed judgment on, so it made sense not to waste time and energy scrutinizing them.
Or more simply as Robert Zajonc says:
If it is familiar, it has not eaten you yet.
There's not much surprising about this - we see businesses exploit this phenomenon to peddle their wares all the time. Drug companies, for example: Sildenafil citrate anyone? "Umm...sounds scary." Viagra? "Maybe so".
Even further, controlled experiments have shown some pretty surprising (and scary!) behavior. Alter and Oppenheim, for example, show that the "fluency" of a company's ticker code (e.g. "GOOG" vs. "DFJK") can positively affect the stock price. Or Schwarz demonstrates that people answer questionnaires less honestly when written in a less legible font. And many others.
So what does this have to do with software development? Some, I think.
Programmers, in my experience, are a thoughtful, deep-thinking lot. We understand that the problems we confront are inherently complex (business logic is anything but logical), and oftentimes require complex solutions.
The problem, however, is often not in how we formulate our ideas but rather how we sell them to our friends up the chain of command: to managers, clients, and executives. Basically, we focus so much so much on conveying the substance of our ideas that we neglect or downplay how we convey them. In other words, we forget about the fluency of the message.
Sure, the battle-worn programmer has of course learned to refrain from "talking technical" to the business side, but I think it goes further. Stuff that seems insignificant, like how we format our emails or documents, the names we use for our proposals or practices (e.g. "continuous integration" vs. "daily build"), the clarity or brevity with which we speak, or perhaps even how we dress can have a definite impact on how trustworthy or wise our ideas seem to others (especially those who know us least). In other words, how they feel about the package of our ideas transfers to how they feel about the substance of them.
This obviously plays a part, for example, in the success of certain vendors selling agility, swappability, peace, and prosperity under the guise of a tidy moniker like "service oriented architecture" and its supporting cast "loose coupling", "orchestration", etc.. Sure, we know these aren't silver bullets, but the truth is that these ideas are very "fluent" to the business side, and so they just seem more "true".
In the end, don't dumb down the message, just spruce it up a bit - i.e. pay attention to fluency. And if you're going to name your idea, maybe try to make it rhyme.
