The Software Industry Record of Failure and the Part BDD Answers

Software has a poor delivery record, and it has had one for as long as anyone has measured. Projects arrive late, cost more than planned, or deliver something the people who asked for it do not want. Behaviour driven development was proposed as an answer to one specific part of that, and it is worth being precise about which part, because the practice is sometimes sold as though it addressed all of them.

A caution about the numbers

The often-quoted figures on project failure come largely from consultancy surveys with self-selected respondents and definitions of failure that have shifted over the decades. They have been criticised on both counts for a long time, and a specific percentage should not be leaned on.

What survives the criticism is the qualitative pattern, which is consistent across sources: when practitioners are asked what went wrong, requirements problems appear near the top far more often than technical ones.

The three requirements problems

They are not the same problem and they do not have the same answer.

Incomplete requirements means something was not asked about. Iterative delivery helps, by shortening the gap before the gap is noticed.

Changing requirements means the need moved. This is usually not a failure at all, and treating it as one is its own pathology.

Requirements understood differently by different people is the third, and it is the one that produces the most expensive kind of failure, because nothing looks wrong until delivery. Everyone agreed. They agreed to different things.

The part BDD addresses

Only the third. The mechanism is narrow and specific: make the agreement concrete enough that two people who understood it differently find out immediately rather than at the end.

Concrete examples do that in a way descriptions cannot. Large withdrawals need approval can be agreed by two people who mean 500 and 5,000. Given a withdrawal of 5,000 forces the number into the open. That is the whole of the claim.

The parts it does not address

Almost everything else. BDD has nothing to say about a project that was underfunded, staffed with people who had never done the work before, blocked on a dependency outside the team’s control, or cancelled because the sponsor left.

It also does not help a team that has been told what to build by someone who will not discuss it, because the conversation the practice depends on is not available. In that situation the scenarios can still be written, and they will faithfully record an agreement that was never made.

Being clear about the boundary is worth more than overclaiming. A practice that solves one failure mode well is useful. One that is presented as solving all of them gets adopted widely, fails to deliver, and takes the reputation of the specific mechanism down with it.

Why a narrow claim is the strong one

There is commercial pressure to describe any practice as addressing project failure generally, and BDD has had its share of that treatment. The result is predictable: a team adopts it expecting relief from problems it does not touch, gets no relief, and concludes the practice does not work.

Stated narrowly it holds up well. Two people who agree on a sentence and disagree on its meaning will discover that when they are forced to write down a specific case. That is almost tautologically true, it is cheap to test on one feature, and a team can verify it for itself in an afternoon rather than taking it on authority.

What to measure if you want to know whether it worked

Not scenario count, and not coverage. The signal is how often a piece of work is reopened because it did what was asked and not what was wanted.

That number is usually not tracked, which is itself informative. Teams that start tracking it often find the category is larger than anyone assumed, and it is the only category BDD claims to reduce. If it does not move after a few months of genuine practice, the conversation is probably not happening in the way the practice requires, and the scenarios are being written by one person afterwards.