I wish he talked about specification's real problem. There are many ways out there to write specifications. Some are good, some are bad. Let's assume we got a

I wish he talked about specification's real problem. There are many ways out there to write specifications. Some are good, some are bad. Let's assume we got a very good one. Then let's say I actually implement the specification correctly. So now I have a program and a spec it matches. But then comes the problem: My application needs to change. Along with it, we need to change the specifications. If said specifications are too high level, then we start changing code without changing spec, and it doesn't take long before the spec is a dead document. If the spec is too low level, then change is hard, because the specification's friction becomes unbearable quickly. So the problem quickly becomes the fact that writing specifications isn't really any easier than writing the code. It's the same problem that plagues many testing suites in practice: They either test too little, or test so much they increase the cost of development way past their value. I am not saying we should not write tests, or specs. But what I really want to know is how to write a good spec, or a good test suite, because if those are bad quality, they actually become detrimental. At work, I just spent a solid two weeks trying to fix extremely overspecified tests: Hundreds of them that should have never been affected by the code changes. The people that write such tests will probably write terrible specifications that are just as brittle. So don't show me a new specification language: Show me how said language makes it easy to write good specifications, and hard to write bad ones.