5 ms·

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

by hubb 17y ago

jrockway 17y 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 17y 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 17y 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.

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

by hubb 17y 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 17y 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 17y 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 17y 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.