On Requirements and Runways – or, are all viewpoints valid?

I came across this cartoon recently.

It's supposed to illustrate that two apparently contradictory viewpoints can both be correct, "from a certain point of view". Or that both viewpoints are equally correct.

It's a cute metaphor, but does it hold up to reality? And is it helpful?

Now in software development, this isn't a theoretical question. We depend on precision and clarity, Are both viewpoints really equally valid? And how do we know?

Let's consider a real-world example of this. What number do you think this paintwork represents? Is there any ambiguity?

What do you say?

.
.
.
.
.
.
.
.
.
.
.
.
Turns out, there is no ambiguity possible.

If you said "60", unfortunately, you are wrong. The correct answer is "09".

How can I be so sure?

Let's take a look at this number in a broader context. The photo below is the east-facing runway at Liverpool's John Lennon airport:

Airport runway numbers are not arbitrary - they represent the compass bearing the runway faces, to the nearest 10 degrees. So 36 (360) represents north, 18 (180) represents south, 27 (270) would represent west. And 09 (90) represents east.

600 degrees (60) doesn't exist, so you could never have a runway with this number.

So, in this context, there are not two equally valid viewpoints.

The guy saying "6" is wrong.

But you could only know this if (a) you know this is a runway number, and (b) you are aware of the conventions.

That's why it's so critically important to understand our requirements, for EVERYONE to understand the requirements, as early and as clearly as possible.

That's why it's so critically important to deliberately query, question and cross-examine new requirements when they come to us.

That's why its so vital to understand not only WHAT a requirement is asking, but WHO is asking for it, and WHY.

And that's why experienced teams use structured collaboration techniques like Example Mapping, Feature Mapping, Pirate Canvases, Impact Mapping and others, rather than just free-form conversation, to understand a new requirement.

If you want to explore some techniques to get clarity around those requirements, take a look at the "BDD from Start To Finish" free training - it shows many of these techniques in their context as part of a full BDD development process.

And if you want to go more in depth, be sure to check out the Serenity Dojo "BDD Requirements Discovery Training" - it covers all of this stuff in a LOT of detail.

Enjoy your flight!