Four Candles? The Perils of Forced Ambiguity
Forced Ambiguity has no place in the Requirements process.
I am sure many readers have seen one of the greatest comedy sketches of all time, if not, or just to brighten your day, here’s the sketch:
For me, this sketch is extremely relevant when talking about the Software Development Life Cycle and how to effectively communicate. To sum up this scenario, the buyer has entered the shop and stated his requirements, he’s then expecting the seller to know exactly what those requirements are.
This fails effective communication on a number of levels. The seller doesn’t clarify exactly what the buyer wants, and the buyer uses ambiguous and implicit language when stating his needs.
I could talk for a long time about effective 2-way communication, but for the purpose of this post, I’m going to focus on the buyer from the above scenario, and communicating effectively when writing tickets for development.
How do we write effective tickets?
Well the first step is communicating exactly what the requirements are. In order to do this, the language used needs to be easily interpreted so as not to force ambiguity onto the reader. As in the Two Ronnies sketch, “four candles” has been forced onto the seller. By changing the wording of the requirements, then that ambiguity is completely lost and “handles for forks” is easily understood.
The sketch continues, but the seller doesn’t appear to learn from his mistakes, and more ‘Forced Ambiguity’ from the buyer continues the comedy for the viewers benefit.
If we look at politics as another example of ‘Forced Ambiguity’, language can be seen as extremely important, but for exactly the opposite reasons that we would want in effective ticket writing. How many times have you watched a TV interview with a politician, where they’ve been asked a direct question, and the response in no way answers the question put to them.
Requirements
We at ResponseTap base our architecture in AWS, the following requirement is not too far removed from what we might expect to see in a refinement session or ticket in a sprint:
“Move data into S3 bucket and update the record if it exists.”
There’s one word in this statement that I believe has no place when writing tickets or communicating requirements — “it”. Look back at the requirement. What does “it” refer to in this example? The S3 bucket or the record?
This is absolutely the definition of ‘Forced Ambiguity’. Here the reader is subconsciously tasked with decoding the requirement, in doing so, the reader is making an assumption. Most individuals would assume the requirement as referring to the record. This is based on the experience of the reader, but everyone’s experience to this point in their careers has been different, so the likelihood that someone within a development team will interpret “it” to mean the S3 bucket is increased.
Forced Ambiguity
Let’s take a look at another example of ‘Forced Ambiguity’:
“He rode a black horse in red pyjamas.”
Who’s wearing the pyjamas?
Again, experience would tell us that the horse rider would be most likely to wear the pyjamas in this scenario. But ‘horse pyjamas’ do actually exist! This means that there is a scenario somewhere that the reader would interpret the pyjamas to be worn by the horse.
Let’s rewrite the previous statement:
“The horse rider was wearing red pyjamas.”
How does this sound? Is this better?
What happened to the horse?
Explicit
When writing our requirements, we need to be explicit with what we are trying to communicate:
“The horse rider was wearing red pyjamas, whilst riding a black horse.”
We want our requirements to be easily understood. We’re not politicians, so we want our requirements to be unambiguous and force no assumptions on the part of the reader. In rewording this statement, we have made note of the main components, the horse rider is wearing the red pyjamas, and that the black horse is being ridden by that horse rider.
As Engineers, we are all responsible for Quality, the more Quality we can inject earlier in the SDLC, the more Quality we can retain as we proceed and as tickets change hands multiple times throughout development.
This is known as ‘Shift Left.’
Relevance
Back to our S3 example, the requirement should be reworded along the lines of:
“Move Call data into Calls S3 bucket, and update the S3 Call record, if the record exists in S3.”
We could include a lot more detail in our requirements, but I would strongly advise keeping the detail to that which is relevant. Going in the opposite direction and including too much detail will prove just as inefficient as not providing enough detail — remember, everyone will have to subconsciously decode that detail.
Have you been affected by ambiguous requirements? Has this resulted in scope creep and refactoring?
ResponseTap Engineering is an exciting, brave and dynamic team, using the latest tech, in the heart of Manchester. Join us.
