Is that clear for everyone?

Software is, fundamentally, a translation exercise.

But what if our intent is unclear? What if there are omissions in what is asked for or the language we use can be interpreted in different ways?

Asking for clarification before we move on can be regarded as the right thing to do. After all, if we're having work done on our house wouldn't we expect that of the builders? Or would we be happy for them to make the decision for us and settle the bill at the end of the job irrespective?

I was asked to review a requirements document prior to it going to a vendor for work. In there, I found that the author had requested different screen output formatting based on numeric values. Up to a value, the data should be shown in green. Above that value, the data should be shown in red. Apart from the obvious challenge for people with red/green colour vision issues, the author hadn't said what to do AT the value.

At best, the vendor would have raised this as a query themselves, with the attendant delays in communication etc. Maybe they could have tried to infer the intent from other parts of the document or, at worst, simply guessed and hoped that they got the 50/50 right.

So what about inference?

There's one English sentence of 7 words where placing the stress on a different work each time gives 7 different meanings.

"I didn't say he stole my money"

"I didn't say ..." tells the hearer that "someone" has made an accusation of theft, but not me.

"I didn't say ..." is a denial of or correction about having made an accusation.

"I didn't say ..." lets the hearer know that there's a strong implication of belief that the theft has taken place, without the outright accusation.

"I didn't say he ..." points out that the accused is the wrong person.

"I didn't say he stole ..." but I'm happy to say that he'd moved it form where it was placed. Whether this was for genuine safe-keeping or with criminal intent is up for grabs

"I didn't say he stole my money" but I believe that the money he have has been stolen from someone

"I didn't say he stole my money" although I'm certain he has taken something of mine.

A quote that I've seen attributed to former US president Richard Nixon goes,

"I know you believe you understand what you think I said, but I am not sure you realize that what you heard is not what I meant." This could be used by so many when faced with a bug in software that has been delivered to them.

How do we close the gaps?

The use of natural language is flawed, especially across international teams with different native languages. Formal specification methods, such as Z Notation and even UML, may be regarded as impenetrable by business users and so have limited use. Proponents of BDD and TDD may cite their preferred methods as 'the silver bullet/holy grail" and these undoubtedly have value, but please don't use Cucumber for complex collections of 10s of conditions or outputs to describe the GIVEN, WHEN or THEN. BDD and TDD are approaches to creating a shared understanding of the intended outcome, not a means to deliver coding or testing.

From personal experience, I have used "Software Inspection" and "Specification by example" in different contexts to great effect.

Irrespective of which method you use, make sure that you say what you mean and that you mean what you say when talking about the intended outcomes. In doing so, you increase dramatically the chances of delivering for success.

"Software Inspection" by Tom Gilb/ Dorothy Graham (Addison-Wesley ISBN 0-201-63181-4))

"Specification By Example" (Gojki Adzic (Manning ISBN-13:978-1617290084))