WHY HAVE YOU NOT INCLUDED THE QUINTESSENTIAL ‘WHAT IF LINUS GOT HIT BY A BUS’ LINK, YOUR SENSE OF HISTORY SUCKS EVEN MORE THAN ERIC RAYMOND’S EGO. That is all.
Linus is often right when he sees a problem with modern software engineering practice, but his solution is often a bit misguided. Though, I agree with him totally about specs. The only spec that is anything more than a possibly helpful guideline is code. And specs are at their best when they’re a description of how something works, not how someone thinks it should work.
But, the code splitting thing… Well, yes, having some obnoxiously huge amount of functionality with gobs of special cases all wrapped up in one thing is a bad idea. But the solution is often not a full split. The solution is factoring out the common code into parts that can be shared, and parts that can’t.
For drivers and things, I bet that is often very little code at all. But I don’t have either Linus’ nor ESR’s (likely rather exaggerated) depth of experience.
Anyway, enough of being serious and unfunny. :-)
I recently visited your site after reading an article in CPU magazine. I must admit this is quite the funny comic strip. Keep up the good work! This rates on my laugh-o-meter right up there with BOFH and User Friendly. I hope you keep the laughs coming.
I’m afraid this comic strip rates rate with the BOFH and User Friendly.
Linus sucks.
Hilarious strip as usual. Kidding aside, though…
In the SE world, there’s two things that commonly go by the name of “specifications”: requirements specifications and design specifications. Design specs, as they are currently practiced, tend to be pretty redundant with other artifacts such as code or pseudocode, and have the other defects attributed to “specs” by those complaining about them.
Req specs, on the other hand, are an essential part of good SE practice when done properly. Having figured out what the user wants (requirements gathering), you organize this information in a form that helps you prioritize user requirements, figure out what the architectural design should be, and check whether your design and code has achieved its goals. The idea that “whatever you build must have been what the user wanted” has been responsible for all kinds of badness over the years.
Admittedly, req specs are usually done wrong: miles and miles of numbered paragraphs that are impossible to comprehend and thus mostly useless. Worse yet, the req spec often describes only functional requirements, leaving out requirements of performance, reliability, security, etc.
In OSS projects, req specs are often developed as increments to current functionality rather than “of a piece”, and are maintained in Bugzilla (of all places) using its voting process. IMVHO a very-high-level requirements roadmap for the Linux kernel would be a useful document. (Maybe it exists somewhere, but I’m not aware of it.) Realistically, though, I don’t see it happening anytime soon.
I appear to be gifted.
Indeed you are. Please don’t stop drunkenly flaming ESR by the way, ever.
14 replies on “Specificator”
WHY HAVE YOU NOT INCLUDED THE QUINTESSENTIAL ‘WHAT IF LINUS GOT HIT BY A BUS’ LINK, YOUR SENSE OF HISTORY SUCKS EVEN MORE THAN ERIC RAYMOND’S EGO. That is all.
http://web.archive.org/web/20000422005356/http://segfault.org/story.phtml?mode=2&id=38b40d78-087dd360
Is Linus wearing a Knuth shirt? Well, Kuth is a *real* CS god! :P
Haha! Where can I buy that sweet Knuth shirt?
“Knuth is my homeboy?”
Knuth has a Posse.
That was a pretty good post/essay. The part that impressed me most was the enormous sig with *gasp* hrefs? Who the crap embeds HTML in email?
“I’m rich. I go by car.”
*rotfl*! But I thought ESR’s the one who’s rich? Worshipping capitalism and all that… :-)
bi: see http://geekz.co.uk/lovesraymond/archive/open-shares
Linus is often right when he sees a problem with modern software engineering practice, but his solution is often a bit misguided. Though, I agree with him totally about specs. The only spec that is anything more than a possibly helpful guideline is code. And specs are at their best when they’re a description of how something works, not how someone thinks it should work.
But, the code splitting thing… Well, yes, having some obnoxiously huge amount of functionality with gobs of special cases all wrapped up in one thing is a bad idea. But the solution is often not a full split. The solution is factoring out the common code into parts that can be shared, and parts that can’t.
For drivers and things, I bet that is often very little code at all. But I don’t have either Linus’ nor ESR’s (likely rather exaggerated) depth of experience.
Anyway, enough of being serious and unfunny. :-)
I recently visited your site after reading an article in CPU magazine. I must admit this is quite the funny comic strip. Keep up the good work! This rates on my laugh-o-meter right up there with BOFH and User Friendly. I hope you keep the laughs coming.
I’m afraid this comic strip rates rate with the BOFH and User Friendly.
Linus sucks.
Hilarious strip as usual. Kidding aside, though…
In the SE world, there’s two things that commonly go by the name of “specifications”: requirements specifications and design specifications. Design specs, as they are currently practiced, tend to be pretty redundant with other artifacts such as code or pseudocode, and have the other defects attributed to “specs” by those complaining about them.
Req specs, on the other hand, are an essential part of good SE practice when done properly. Having figured out what the user wants (requirements gathering), you organize this information in a form that helps you prioritize user requirements, figure out what the architectural design should be, and check whether your design and code has achieved its goals. The idea that “whatever you build must have been what the user wanted” has been responsible for all kinds of badness over the years.
Admittedly, req specs are usually done wrong: miles and miles of numbered paragraphs that are impossible to comprehend and thus mostly useless. Worse yet, the req spec often describes only functional requirements, leaving out requirements of performance, reliability, security, etc.
In OSS projects, req specs are often developed as increments to current functionality rather than “of a piece”, and are maintained in Bugzilla (of all places) using its voting process. IMVHO a very-high-level requirements roadmap for the Linux kernel would be a useful document. (Maybe it exists somewhere, but I’m not aware of it.) Realistically, though, I don’t see it happening anytime soon.
I appear to be gifted.
Indeed you are. Please don’t stop drunkenly flaming ESR by the way, ever.
– Chris