Weekly Edition
Return to the Kernel page
| |||||||||||
Quotes of the week
visionary [n]: onanist with strong exhibitionist tendencies; from
"visions", the source of inspiration they refer to when it becomes
obvious that they have lost both sight and capacity for rational
thought.
-- Al Viro
A "spec" is close to useless. I have _never_ seen a spec that was
both big enough to be useful _and_ accurate.
-- Linus TorvaldsAnd I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality. (Log in to post comments)
In defense of specs Posted Oct 6, 2005 19:35 UTC (Thu) by robla (subscriber, #424) [Link] I particularly like this response to Linus from Hua Zhong. I know from my work doing standards work that spec are WAY overratted, and that it's way too easy to take them way too seriously. However, they are a necessary evil in many, many situations.Specs are a lot like contracts. Much in the same way a business contract never 100% expresses the true nature of a business relationship, a spec isn't going to be perfect. If you constantly find yourself going back to the business contract to make sense of your business relationship, your relationship has a lot of problems. Similarly, if you have a standard API or software spec that you need to refer to the spec to really understand what's going on, there's probably something wrong with the API (and thus, the spec). However, it's tough to have a deep business relationship without a contract, and it's tough to have two implementations of interoperable technology without a spec. The process of writing a spec is really handy when the right people are at the table. It's in essense a negotiation between important parties to agree on a shared direction. The best specs (e.g. ANSI C) start off with working code, then the spec, then more independently-developed working code implemented from the spec. I'm hard pressed to come up with an example of a really great spec that didn't start from documenting a fully-functional implementation already in widespread use. Perhaps Linus is right in that specs have never worked for his situation. He doesn't negotiate after all; he's the benevolent dictator. In a world where there's only one codebase to worry about, well-documented code is probably going to be a less error prone means of collaborating with him.
In defense of specs Posted Oct 8, 2005 5:58 UTC (Sat) by roelofs (subscriber, #2599) [Link] I'm hard pressed to come up with an example of a really great spec that didn't start from documenting a fully-functional implementation already in widespread use.PNG? I will allow as to how the PNG spec wasn't actually completed until after at least two full implementations existed (maybe more). But it was definitely started, and arguably even "mostly finished," before such an implementation existed. ObDisclosure: I'm not even remotely close to being an unbiased observer. ;-) Greg
The use of specs Posted Oct 13, 2005 12:22 UTC (Thu) by rvfh (subscriber, #31018) [Link] I personally feel specifications necessary. Even though they might be just 5 lines explaining what it is the software is going to do (or does). They set the boundary of the project and allow for time estimation, which are obviously two notions the Linux kernel does not need to care about... but companies do!
|
|||||||||||