Precision of Language Please - The Art of Getting Stuff Done...Right

A shout out to my friend and fellow Notre Dame alum Robert J. Szcerba who presented this problem on his page.

This 'question' in the image above illuminates a common problem that shows up in the work force. The question itself is clearly stated and appears fairly straight forward. However, there are a number of nuanced ways that one can interpret the question that lead to different answers. Before we talk about the more general situation and consequences, let's walk through this example. Spend a minute to work through how you would answer this. Once you are ready, skip ahead to the next paragraph. ...

Okay, let's look at a couple of ways to answer this question. First note that the answers are composed of two elements - an answer label (A, B, C, D) and the corresponding values (25%, 50%, 60%, 25%). You're asked to randomly choose an answer.

We've hit our first ambiguity - what is meant by 'answer'? Is it the answer label or the associated value. I've had people argue aggressively for both sides. So let's look at both options and see where they take us. If you decide the 'Answer Label' is what is being looked for then you have four choices (A-D) and assuming a flat random distribution (itself another ambiguity embedded in the question), there will be a 25% chance of identifying the correct letter choice...assuming there is one ... and assuming there is not more than one correct choice (ambiguities 3 and 4).

Alternatively if you believe that the Answer Value (25%, 50%, 60%, 25%) is what the question poser is intending with this question, then you hit another issue. Two of the values are the same. The author further complicates this puzzle by asking for a chance that you guess right. And then providing answer values that themselves could be interpreted as 'chances'. For clarity with the current interpretation of the question, let's change the problem to have animal values (cat, dog, zebra, cat). And then ask what are the chances to guess the correct animal. 50% of time you'll guess a cat; 25% dog; 25% zebra. Three animals, on average a random choice will have you right 33.3% of the time.

Note in both these interpretations, the definition of 'correct' is unknown. This itself is an assumption by the reader. The question poser does not clearly indicate that the correct choice is or is not among the Answer Values. (ambiguity #5).

There are several other paths one could take answering this question. I'm not going to waste your time walking through them. Suffice it to say - This straight forward 'question' isn't really straight forward.

Why is this important?

Let's step back and consider our work environments. Typically, a manager will present staff with a problem or task that needs handling. Requirements are gathered, a design is chosen, subtasks are created and distributed among a team of programmers. The programmers complete their subtasks. The end product is generated by combining the output of the various subtasks.

This all sounds so much more complicated than the simple question above. The opportunity for embedded ambiguity (and errant behavior) is correspondingly higher.

I would argue that human language is inherently ambiguous. And needs to be in order to express complex nuanced thought. This means that Precision of Language sufficient to remove all ambiguity is a lost cause. But necessary anyway.

What do I mean by this?

The only viable recourse is intelligent testing by each node of the information transfer chain (i.e. each person). The chain is strongest when each person's work integrates properly with everyone else's work.

Everyone needs to apply basic 'sniff' tests to the work they do. Does it smell funny? Does it make sense this thing that I have my code doing? How does it fit into the larger solution? If your staff are not asking these questions, you're going to have problems. Your senior staff will have the most common sense (aka experience). But they can't watch over everyone's shoulders or do all the work themselves. You've got to grow your more junior members. You do this by training them to think about more than just the proximal task. You facilitate this by doing your best to keep your requirements precisely defined and then providing illuminating fully described use cases. Finally, pair up your programmers (one senior, one junior). Have all code written by one, reviewed by the other.