Linus On Specifications (2005)

by nreece • 16 years ago

18 9 16 years ago

olalonde• 16 years ago

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• 16 years ago

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

shin_lao• 16 years ago

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• 16 years ago

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

hubb• 16 years ago

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

jrockway• 16 years ago

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• 16 years ago

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.

psranga• 16 years ago

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.

arethuza• 16 years ago

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

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.

Linus On Specifications (2005)

Related Stories