Behaviour Driven Programming: What the Term Means and Where It Is Used

Behaviour driven programming appears in the literature in two senses, and the difference between them is small but occasionally useful.

Most often it is simply a synonym for behaviour driven development, used interchangeably and meaning the same practice. Where a writer keeps them apart, the distinction is one of scope.

The narrower sense

In the narrower reading, programming names the coding activity: implementing against specifications that are stated as behaviour, in a red-green loop, in the same rhythm as test driven development but with the outer specification written in the language of the domain.

Development, by contrast, covers the whole practice, including the conversation that produces the specifications, the decision about what is worth building, and the organisational habits that keep the examples honest.

The distinction has some use. A developer who wants to describe how they work at the keyboard without claiming their organisation has adopted a practice has a phrase for it.

Why the broader term won

Behaviour driven development is the term Dan North used, and the one the tooling, the books and the job adverts settled on. Anyone searching the narrower phrase will mostly find material about the broader practice.

There is also a reason of substance. The value of BDD is concentrated in the part that is not programming. A team that implements flawlessly against specifications nobody discussed has kept the cheap half and discarded the expensive one. Naming the practice after the programming risks implying the opposite.

Where you will meet it

Chiefly in older material and in translated writing, where programming and development are not consistently distinguished in the source language. It also survives in a handful of framework names and a few library descriptions from the mid-2000s, when the vocabulary was still settling.

Treat it as a synonym unless the surrounding text is clearly drawing the narrower distinction, and look at a worked example if what you want is the mechanics rather than the terminology.

Related terms with the same problem

The vocabulary around this practice has several near-duplicates, and they cause more confusion than the underlying ideas do.

Behaviour driven testing names the automation half: running example-based specifications against a live system. It is accurate as far as it goes and puts the emphasis back on testing, which is the emphasis the original renaming was trying to move.

Specification by example is a genuine alternative name for substantially the same practice, associated with Gojko Adzic’s book of that title. Some practitioners prefer it precisely because it contains no reference to testing or development and so invites fewer arguments about whose job it is.

Example-driven development appears occasionally and means the same thing again.

None of these distinctions is worth a disagreement in a planning meeting. What matters is whether a team writes concrete examples together before building, and no choice of noun makes that happen or stops it.

Why the vocabulary keeps multiplying

Because each name is an argument about ownership. Testing puts the practice with whoever owns quality, development with whoever writes code, specification with whoever defines requirements. Every rename is an attempt to move it somewhere the objections are quieter, which is the same move Dan North made when he replaced “test” in the first place.

That is worth recognising when a new synonym appears. It usually signals that somebody met resistance under the old name rather than that the practice changed.

What to do when the terms collide in a team

Pick one and stop discussing it. The disagreements the practice is meant to surface are about behaviour, and a team that spends its conversation arguing about what to call the conversation has found an expensive way to avoid the work.

Where a term genuinely causes trouble, it is worth changing rather than defending. If “behaviour driven development” makes a manager hear a new phase in the schedule, calling the artefacts examples and never naming the practice at all is a perfectly good response, and closer to the original intent than insisting on the label.