When people say ‘Spec Driven Development’ — all the examples I see are natural language specifications of a solution that someone wants an agent (or few) to implement. It’s often discussed as something adjacent or in addition to Test-Driven/Behaviour-Driven Development, when in fact TDD/BDD are themselves spec-driven techniques — let me explain…
TDD / BDD are “Specification by Example” methods, driving development incrementally and iteratively through a living, self-verifying, executable specification. They allow you to evolve the product as you evolve your understanding of the problem(s) that it solves.
You express your understanding of a given problem, one example at a time, evolving the solution in small steps to address the aspect of a problem that each example illustrates.
For example, you know when you’re explaining a problem to someone and you say… “for example”, then elaborate on the context and consequence of what can happen? See what I did there?
In our case, each example is expressed as an automated test, before the software actually solves the problem it illustrates.
Sometimes, the question arises: how can you write a test for something you haven’t built yet? I say — how can we implement a solution for a problem we don’t understand enough to provide examples of yet?
“if you can’t explain something in simple terms, you don’t understand it”
–Richard Feynman
In short — Specification by Example approaches like TDD/BDD are a ‘newer’, and improved method for specifying software. They leave us with a self-verifying, executable specification that checks that, with each evolution to the product, it also continues to solve the problems we got it to solve in the past.
And this is the issue with most illustrations of so called ‘Spec Driven Development’ — they are a spec for the solution someone has in mind, not of the problem that solution must solve.
Still, after 25+ years of having this conversation — no really, just Google it — people are still talking like TDD & BDD are principally about “testing” and not as a Specification by Example technique.
So, to me, when people use the phrase ‘Spec-Driven Development’ today, what they are really saying is ‘Waterfall Development’ with many of the same downsides — just realised faster with AI.