In a previous post I introduced the topics of poor quality language giving rise to poor quality output from software teams.
Here, I want to go into more detail on three major bad habits which frequently mark such communications. I would categorize the following mistakes as mistakes of “laziness”, although we should be careful to qualify what that word means. In this usage of “laziness”, there is no implication of willful lack of consideration; rather the mistakes derive from a combination of over-familiarity with language, and lack of conscious understanding of the importance of good quality language in communications.
It’s important to note here that it isn’t just in the domain of technical specifications where these faults can cause issue. Casual conversations about, say, project management or working environment or general policy can all suffer from the following bad habits.
Let’s get into it:
By “ambiguity” we mean the effect whereby some description may be interpreted in multiple ways, and where the intended interpretation is not made sufficiently clear as to be perfectly obvious.
It is fairly obvious why ambiguity is a problem when it comes to technical specifications. By definition, something which is open to interpretation is not entirely specified. A crude example of ambiguity in specification:
There must be a login widget presented to the user.
A “login widget”? What’s that? Maybe the “login” part we can infer, but “widget” – does that suggest something about presentation, or placement, or usability? Talking about placement – none is made explicit here. Does it not matter where exactly this “widget” is “presented to the user”? And how about the temporal dimension? Should the “login widget” always be “presented to the user”, or only once, or only in certain circumstances?
You get the picture. This is a very obvious case of ambiguity by omission of information in what is clearly a context of specification.
Here’s a much more subtle (and very common) example in a project management context:
The project will be delivered by 11th October 2014.
Firstly, we’re presumably supposed to have a shared understanding of what the scope of “the project” is. Let’s hope that is at least true (often not). Secondly, are we all clear on what “delivered” really means? It is an extremely common fault to leave this open to interpretation. That’s why you’ll hear Agilists banging on about “Definition of Done” all the time, although often abbreviated to the rather irritating DoD (Dee-Oh-Dee).
The last problem with a statement like this is the word “will”. Now, anyone who’s delivered at least one software project knows the problem with making unequivocal time commitments. But surely anyone who’s commissioned at least one software project also knows the problem, so we should all be on the same page, right?
Short answer: no.
Long answer: maybe, but why leave it to chance? The word “will” is such a short one but the implications of using it are extremely powerful. I’m not saying you have to use some vague and weak alternative, such as “might” – but you might consider at least attempting to quantify the risks.1
Some of this talk of unambiguous specification may raise alarm bells with certain Agile practitioners out there. After all, isn’t Agile all about lightweight documentation and collaborative specification? Yes, it is – but it isn’t about zero documentation or zero specification. (Don’t believe me? Read the third paragraph of the Agile Manifesto)
And more to the point – if you’ve already had the conversation, and decided to write something down, why not do it as accurately as possible?
Or to put it another way, I’m not really advocating any particular level of specification here – I’m just saying that we have a duty when communicating with each other that whatever we agreed to specify is transmitted faithfully.
Subjectivity could be seen as a sort of specialized form of ambiguity. It arises when some description has a different meaning to different people.
The difference could be strictly semantic, and this is often a function of cultural boundaries – both geographical and temporal. Consider, for example, how the common meaning of the word “gay” as an adjective has changed over time even within a single Western culture like the United States.
Very often, the difference is simply one of magnitude. Consider this example of a specification:
The user interface must be clean and uncluttered.
There is no semantic ambiguity here. Most can agree that “clean and uncluttered” means “without excessive detail, or unnecessary visual elements”. In the translation we see the problem of magnitude though: how do we define “excessive”? How do we decide what is “unnecessary”?
Or how about a request that some line manager makes to one of her reports:
I would like you to try and conduct yourself more professionally than you currently do.
What does “more professionally” really mean? To you? To me? Can we expect that they are the same thing?
This one is interesting because we note that there is no explicit ambiguity in a relative sense. If we could score the employee’s current professionalism on some numerical scale (assuming we know how to measure professionalism), the request would appear to be satisfied by shifting said professionalism merely one “notch” higher on that scale.
Of course, we might more realistically suspect that there is actually some specific target of professionalism implied here, on the same hypothetical scale, and that target remains unstated here, which could be an issue for the hapless underling.
It might seem like rather a no-brainer that subjective language is not ideal, especially in specifications. But we use it all the time, especially when we deal with issues of emotion, or situations in which emotion is or might be involved. Indeed, it’s ironic to note that often the act of questioning subjective language can generate an emotional response.
This conversation sound familiar?
Stakeholder: I’m not happy with the performance of this. It needs to be much better.
Engineer: In what way specifically does the performance need to be better?
Stakeholder: Well, if you have to ask that then maybe you’re not the right person to deal with this! Hrumph!
Or how about this?
Forum Newbie: I am a Scrum Master. My team don’t care about anything. How can I make them care more?
Glutton for Punishment: What do you mean by “don’t care”? How would it look if your team “cared more”?
Forum Newbie: They just act like they don’t care, and they don’t listen to me when I tell them to care more!
People aren’t mind-readers, and when we get emotional – when we feel threatened or scared or angry or undermined or not listened to – we are especially susceptible to forgetting that.
The best way to resolve a situation when emotions are running high is to take care to communicate what we need in specific terms, rather than subjective ones.
There was another contender for the third bad habit, and that was “jargon”. I’m actually going to make that the subject of an entire post of its own, which is why we’re left with “platitudes”.
Platitudes are quite insidious beasts. They arise when someone communicates something which is generally considered to be incontrovertible, or somehow not in contention; and they manifest as trite fragments of language which are barely noticed and rarely questioned. Some examples, together with what they might imply:
We are where we are / it is what it is.
Implication: this discussion needs to end.
Let’s chalk that one up to technical debt.
Implication: we should not consider resolving this.
Better to remain consistent.
Implication: let’s not think about this any more.
Better to beg forgiveness…
Implication: let’s not ask permission.
We might go on indefinitely.
Am I getting my knickers all in a twist over nothing here? Surely these glib little snippets don’t actually harm anyone, they just make our language more colorful. Perhaps they do, but I’ve seen too many conversations shut down with a well-aimed platitude not to have learned to be seriously distrustful of them. Not only are they effective conversation killers, but they can also make it very awkward to resurrect a conversation at a later date.
I feel a law coming up:
Britton’s Law of Platitudes
The more people who gently nod their heads and murmur assent at a platitude, the harder it will be to revisit the original topic of conversation later.
You heard it here first, folks.
The danger of platitudes lies precisely here – when something becomes “established fact”, it’s very difficult to challenge it. Platitudes are like “established facts” which don’t actually state anything, hence the tendency for their “established” status to be displaced to the nearest actual topic of conversation. It’s a little like employing a so-called “straw-man” argument, although actually more like a straightforward decoy.
I’m not saying that all platitudes are used for nefarious purposes, or that everyone who utters a platitude is either devious or naive (I’m sure I’m as guilty as most of using them from time to time). But I think when we’re in situations where communication quality is of critical importance we should be especially mindful that we’re saying things which actually carry real value. Similarly, we should be suspicious of statements which, upon inspection, don’t carry value, because they still have a powerful capacity to influence nonetheless.
I beat up on jargon, and my absolute pet hate: acronyms!