Then the author doesn't actually understand how specs are written and where he should aim his criticism. Pretty much everything that can go wrong with code can

Then the author doesn't actually understand how specs are written and where he should aim his criticism. Pretty much everything that can go wrong with code can go wrong with specs, not because the individual drawing it up is an idiot, but because humans are fallible and the process and communication to reduce the effects of that are lacking. Specs contain bugs, like even code from the best programmers contains bugs. Specs contain duplicate content, because several people worked on it at once and did not have full insight into the part the other was working on. Specs are unclear, like comments from your colleagues on a different project are unclear, because the person drawing up the spec/comment has already soaked up too much domain knowledge to realize his spec/comment is insufficiently explicit. Specs contain missing sections, again because multiple persons were working on it and the division of responsibilities was unclear. Etc., etc. The advantage of code is that it has to compile and execute. You can write tests against it, run code checkers, etc. and find problems early. However, this is not the case for specifications. In that case, the programmer is often the tester and when the inevitable problem is found, the person that wrote the spec should be available for additional explanation, followed by adjusting the spec. This becomes a problem if the person is unavailable or the spec has been approved and re-approving a change is hard or even impossible. In those cases, that is the problem, not the fact that the spec contains a bug. Specs will be unclear. Even after thorough review by programmers, those same programmers will discover problems while implementing the spec, even when they were previously paid to review it to the best of their abilities. The only solution are easy ways of communication to allow for clarification and a process that allows for changes to the spec. Actually, there is an intermediate solution: use the spec directly to create a model of the spec which can be used to automatically create testsuites for the implementation. While creating the model, you will already find many problems and the automatic testsuite can cover many cases that no manually written testcase would cover. In some cases you can even use model checking techniques to prove the spec allows for undefined behavior, such as a deadlock.