Linus didn't exactly shine in this discussion :/ Especially the part where he says: A scientific theory is an approximation of observed behaviour WITH NO
KNOWN HOLES.
Once there are known holes in the theory, it's not a scientific theory. At
best it's an approximation, but quite possibly it's just plain wrong.
Not really. The problems with specs is that you get no feedback when writing them, and as a result, it's easy to completely forget about very important parts.
When you are writing code, you can't forget about important parts. Because if you do, your code won't work at all.
I agree. Mostly. I think we need to remember he's talking about kernel specs. For those of us writing end-user applications, you can (and should!) get feedback during the spec writing process. You write a draft of the spec (which should capture requirements, not include implementation details), put this in front of your users, get feedback, then lather, rinse, repeat. This process won't be perfect, but it gets you closer to reality.
Of course, even that doesn't work for all situations. Some shops can be "agile" enough to quickly get new iterations out there based on feedback. And that can be nice. There are other industries that are very much requirements/documentation driven (see medial software and devices) and the spec does matter.
Yes, you can forget about important parts in code. Been there, done that. Been there, seen that.
Just because the code passes the developer's unit tests doesn't mean that nothing important has been forgotten. Most errors in programs are due to errors in comprehension. Spec review is the fastest and cheapest way to catch those problems. I've done this innumerable times.
Spec hate is a mystery to me. On the one hand, most programmers agree that shorter programs are easier to understand (pg articulated this well), so we go for DSLs, high-level langs etc. A spec is the ultimate short program.
I find specs very useful before starting on a project. It's much easier to for non-programmers (who may be domain experts though) to comment on the completeness of the proposed solution when they see a spec. And developers benefit from seeing feedback before writing code because it's easier to rewrite text than code (Spolsky said this well).
I'm undecided about maintaining specs to be in sync with code forever though. I don't do this except when I make big changes.
What kind of specification though? In most cases, a requirements specification can be pretty useful although I'm not such a fan of up front technical design specifications, in fact I tend towards the "code is the design" viewpoint:
I do agree with the sentiment that processes that focus too much on design artifacts and less on practical issues of how to make working systems often lead to truly awful designs.
I'm also interested in exactly how one would apply an iterative cycle of implement->test->formalize to this category of software? (Ooops. There goes the rocket! Back to the keyboard!)
Once there are known holes in the theory, it's not a scientific theory. At best it's an approximation, but quite possibly it's just plain wrong.