We use similes and metaphors quite frequently, particularly in software. Everything is so figurative and you spend all day coming up with names for things that are “like” real world objects. Of course, that’s not counting those things which are not like anything else other than what they are in software. This is not about them. And this figurative language we carry over into customer engagements too, explaining to our dear customer why the original quote does not hold since they subsequently added the kitchen sink and “tinted windows” 🙂 Not to mention explaining why that takes an extra ‘x’ weeks.
During one such session, it suddenly dawned on me halfway through the metaphor, that the client started extending the metaphor and the proceeded to re-apply it back to the software project, taking it too literally, and ended up explaining to me how software works based on the metaphor at hand. Doh! And all i was trying to do was help educate and understand…
I think IT, in general, has come under heavy pressure to talk the language of the client- and indeed, we are encouraged to keep getting better at this. Make it more accessible so that they understand… Why?
I don’t understand that thing my dentist uses to fill a tooth; nor do i care about the gadget the plumber used to seal the pipes with; and yay for the structural engineer who … well, i really don’t know what he did. But i still use and pay for their services. Did they go to great lengths to explain the intricacies of their tasks? Nope. Did it matter. Not really. I engaged them- they told me how much and how long- i paid, they did it. Moving right along.
I think the more we “passively force” non-programmers to understand what we’re doing, the more confusion we sow. Particularly when the metaphor we use is so accessible, we have no idea how their experiences, assumptions and understandings will impact on the point we’re trying to convey.
As programmers, we owe it to ourselves to forge the language (jargon) we have created, not with the purposes of creating a divide, but so that we can just get on with the job, efficiently. Without the extra fluff. Of course, that’s not to say don’t make an effort to help a client understand, if they want to understand on technical terms. Dumbing it down doesn’t really help, except maybe in polite social discussions 😉