14 Replies to “Specificator”

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

  2. 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. :-)

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

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

Leave a Reply

Your email address will not be published.