Writing software is hard, particularly when the schedules keep programmers “nose to the grindstone.” Every so often, it's important to take a breather and look around the world and discover what we can find-ironically, what we find can often help us write software better.
Life as a programmer is difficult enough, but what happens when even the simplest conversation with other programmers on your team (much less the customers) goes awry?
Everybody's seen it happen before, and I'd be willing to bet everybody's been involved in it before. You're having a conversation with other developers on your team, and before you know it, the voices are loud, the gestures are emphatic, and you're caught up in the classic "You're wrong, just admit it!"/“No, you're an idiot, and I'm right, just accept it!” kind of cycle. I got into one of these energetic shouting exercises myself a few years ago over JavaScript, and whether it had the concept of “types” within it. I maintained that clearly, yes, JavaScript has types within it; my debate opponent was equally certain that JavaScript was a typeless language.
Only via the timeless intercession of a neutral third party resolved what could have been a pretty ugly spat, particularly since my opponent and I had been pretty good friends up until that point. And, worse yet, it turned out that we were basically arguing right past one another-his definition of “type” was fundamentally different than mine was, and as a result, we were arguing apples and oranges.
Oops.
Language Games
Philosophers have wrestled with this same problem, referring to the discussion as “The Beetle in the Box.” Loosely put, it goes like this: Suppose everyone had a box with something in it. We call it a “beetle.” No one can look into anyone else's box, and everyone says he knows what a beetle is only by looking at his beetle.
How do we know we're all talking about the same thing? Certainly we can use external references to somehow identify a “beetle” as being so many inches long and having a certain color and shape, but what about more amorphous terms like “pain” or “difficult?” Up until the middle of last century, the popular view of language was that words were “denotative”-they are basically names or labels that designate things by being attached to them. But an Austrian philosopher, Ludwig Wittgenstein, upended most of the philosophical world (and a few other worlds as well) by pointing out that for certain kinds of terms used to describe entirely subjective experiences, such as “pain,” we can't really be precise about the definition between us, because I can't peer inside your experience any more than you can peer inside mine. Our experiences remain entirely and thoroughly private, at least until such time as technology allows us to directly input someone else's brain storage into our own.
In fact, if you think about it, this actually calls into question every word we use, because our internal process takes an external sensation, and we say to ourselves, "Ah, this must be X*,"* and henceforth you use that word to describe that thing-be it internal or external-forevermore, or at least until different sensations come to attach themselves to the word. As a result, for any given word, its meaning is almost entirely subjective; there can be no independent “criterion of correctness,” nothing outside of one's private, subjective experience to act as a standard. Trying to argue against it would be like arguing against someone protesting, "I know how tall I am!", and laying his hand on top of his head to prove it.
So if we cannot get meaning through what Wittgenstein calls private language, how then do we communicate? Through public language: through words that have meaning “only in the stream of life.” In other words, the meaning of language lies at the surface of consciousness, based on an explicit, shared understanding of a term. Then, because we have a shared understanding of the meaning of language, we have a shared culture of beliefs and assumptions and a common outlook on the world. And thus do we avoid miscommunication.
Which, by the way, leads to rule #1 for any software project: establish a glossary of terms up front, in a public place, so that any newcomer to the group can share in this public language as quickly as possible.
Otherwise, your “agile” is not the same as my “agile,” and suddenly, we're leaning across the table at each other and screaming and shouting again. And that's hardly “agile.” Or polite. Or productive.
“90% of All Disagreements…”
Our industry has a slightly different version of the problem, but it's still related: if I walk up to you, closed box in hand, and tell you I have a beetle in the box, are we communicating? Have I successfully conveyed the idea to you, or are we just fooling ourselves?
In many ways, the answer depends on who you are, and who I am. Given my relatively poor knowledge of beetles and bugs and other such creepy-crawly things, there's about an even chance that I'll mistake some other kind of bug for a beetle, and misidentify the thing in the first place. If you're equally ignorant about the insect family, then the misidentification may go completely unnoticed by both of us. You may have slightly better knowledge than I do, and correct my use of the term “beetle” and replace it instead with the correct term “cockroach”.
But if you have a post-graduate degree in biology and a deep well of factual information relating to all things creepy-crawly, then chances are you will find my statement completely useless and factually ineffective-what kind of beetle? What species? Where did you find it? Why are you keeping it in a box? And so on.
The reverse is also true: if you are a bug aficionado, and you come to me, box in hand, to inform me that you have a brachinus medius in the box, chances are my reaction will resemble that of a US high-schooler upon being told the British Parliament has just voted to adopt an amended version of Robert's Rules of Order as their standard parliamentary procedure document: “Huh?”
The problem of communication often includes not just the basics of having a common vocabulary, but also classic problems of too much or too little information. Throw in problems of communication context, where information doesn't make sense to one party because that party doesn't have the necessary background or context to understand it, and you have all the necessary components for a really good joke.
A helicopter pilot was flying a tour group around the city of Seattle when a sudden fogbank blanketed the entire area. Compounding the problem, a freak electrical surge shorted out his GPS. The pilot needed to return to the airport, but the fog made it nearly impossible to get his bearings. After flying around ineffectually for a few minutes, he spied a distant rooftop, and on top of it, a lone figure stood staring out over the fog.
Bringing the helicopter into a hover, he opened his door and shouted to the figure, "Hey, can you help me? Where are we right now?"
The figure shouted back, "You're in a helicopter!"
The tour group was astonished as the pilot, with absolute certainty, closed his door, banked the copter away, and after a few minutes, left the fogbank and set the copter down at the airport they had left.
One of the tour members asked him what it was the guy said to give him his bearings again. The pilot shrugged and said, "I knew after he answered that we were just outside the Microsoft building in Bellevue, because only a software engineer can give an answer that is entirely factually correct and still wholly useless."
(I'm reasonably certain I worked with that guy, by the way.)
Communication between software developers and non-technical project participants remains one of the greatest challenges of our times, ranking far higher than any technical problem we face. Even when project stakeholders fully appreciate the software developers building the project for them, opportunities abound for miscommunication that can lead to frustration and wasted work.
The problem is not just limited to software developers offering too much technical information to the project stakeholders. All four permutations are possible: the software development team can sometimes offer not enough information for project stakeholders to make an informed decision, and project stakeholders sometimes provide too much or too little information for us to be able to implement the system effectively.
And, unfortunately, this is not an easy problem to solve in a general way-I have no blanketable words of wisdom to solve the problem except for the basic “Recognize that it can happen.” One technique I've found useful when communicating with the non-technical, however, is to describe technical concepts in terms of analogies and metaphors, so long as everybody understands that all analogies and metaphors break down eventually.
More importantly, when getting into a discussion with somebody, particularly if this is someone with whom you've not spent a lot of time in discussions before now, bear in mind that the language used in the discussion may not map yet, and that some clarification of terms may be necessary.
Or, as a friend of mine once put it many, many years ago, “90% of all arguments are nothing more than a disagreement in semantics.”
For those interested in a light introduction to “language games,” I highly recommend the books "50 Philosophy Ideas You Really Need To Know", by Ben Dupre, specifically chapter 32, “The beetle in the box.”
