Well no, the whole point is that the spec is not detailed enough to be code. Of course it leaves out details. I feel like this conversation will diverge to generalities without an example. So, take the WebAssembly spec for example. There's a reason it's written in "spec" language and not just some C code (or any other programming language, for that matter). But that's a very precise spec.

In reality, a loose spec is better than no spec. For example:

1. The loader should be able to parse an input file of up to 100MB in under 1 second.

2. The loader should support XYZ files version 3, 3.2, 3.3, and 4.0.

3. The loader should validate and reject erroneously formatted files.

4. The application should store internal state in robust storage that is independently inspectable.

5. The UI should be able to function if the backend database is down for less than 3 hours.

If you can't write ~1 page of such high-level requirements, why would you expect that you could start writing code? But we do. I mean, even I do!

I absolutely agree that you need requirements. If you don't know what you're trying to build, it makes it really hard to build it. (And, one page? That's hopelessly inadequate for anything real. But I agree, too often we just start writing...)

But I think where the disagreement comes is in the difference between requirements and specification. The example you gave is, in my view, not a spec at all, just requirements.

Take item 4: That could mean anything. It could mean a SQL database with a published schema, or it could mean a 1 GB file on disk that I can view in a hex editor. (The file probably can't be in /tmp though, because you said "robust".)

So people try to make the requirements more specific, so that they "specify" exactly what the software does. And that's where my previous comment comes in - you can't make it specific enough to answer all the questions. Which was one of the points of the article.