

Linus On Specifications (2005) - nreece
http://kerneltrap.org/node/5725

======
olalonde
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._

~~~
eru
Indeed. Newton's mechanics are considered still a scientific theory.

------
hubb
this is more or less re-highlighting linus' reliance and his own talent and
abilities, and his derision for others' reliance on planning

~~~
jrockway
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.

~~~
bmj
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.

------
arethuza
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:

[http://www.developerdotstar.com/mag/articles/reeves_design_m...](http://www.developerdotstar.com/mag/articles/reeves_design_main.html)

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.

------
shin_lao
I agree when he says that trying to model your problem in a specification then
write the software is doomed for failure.

I disagree when he seems to imply that you don't need to document what you're
building.

Being iterative with software and specifications/documentations can lead to
both good software and specifications.

Write a small amount of software, formalize, write some more, etc.

~~~
lucifer
_"I agree when he says that trying to model your problem in a specification
then write the software is doomed for failure."_

Is that a reasonable generalization?

Here is a case where divergence between the model and "reality" would be
catastrophic: <http://www.fastcompany.com/node/28121/print>

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!)

