Specifications
 

Linus Torvalds was recently quoted saying: "Specs are a basis for talking about things. But they are not a basis for implementing software" (see here). In a mechanical engineering context, this statement has no basis: without specifications or standards, the manufacturing and assembly of parts and products could never be separated. But unlike manufacturing, where specifications and standards in no way limit the field (in fact they probably accelerate its growth), in computer science and programming, it is much more difficult to create specifications that are sufficiently specific to be called a "specification" and yet sufficiently broad to be applicable to future technologies and developments. The dilemma that arises is a chicken and egg problem: should the software create the specification, or should it be created following the specification? Do you, as a programmer, find it easier to program for interfaces that follow a specification (like POSIX), or do you simply want them to be intuitive?

Re: Specifications
 

all the real work in engineering happens when you write the requirements spec (what the system shall do), the design spec (how the system is going to do each 'what'), and the test spec (how you are going to test the system to prove it does all the 'whats').

If the specs are not written, or only half written, or you use parts (like interface specs) that are not up to date, or if you have no spec at all, then you are writing code by the seat of your pants.

Engineering has gone through this before - there's always some group of hotshots who think they can figure out what a systems going to do, how its going to do it, come up with the algorythms and data structures on the fly, and make up or fill in the interfaces as you go along.

Thats not engineering, thats hacking.

If your specs are worthless its because the person who wrote them doesnt know what they are doing.

Re: Specifications
 

Agreed, specifications are necessary wherever engineering is involved. I think what Linus is getting at, however, isn't the issue of "vertical" specs so much as "horizontal" specs - I'll elaborate:

A processor is made with certain specifications. These specifications are necessary, so that systems programmers aren't poking around in the dark trying to figure out how to use this new chip. This is a "vertical" specification so-to-speak, because it influences the next step in design - the processor manufacturer tells the system programmer how to write code for the chip, the system programmer then tells the applications programmer how to write code for the OS, and so on. Here, a well designed specification is fundamental to the viability of the chip and its implementation.

On the other hand, consider a specification like POSIX. It is what I would call a "horizontal" specification. If it were called the UNIX specification, there would be no problem, but giving it a name like the "Portable Operating System Interface" has the effect of pressuring non-UNIX system programmers to comply with it, mainly because they know that "POSIX compliance" means "open source community friendly." Admittedly, my question was poorly phrased. What I meant to debate was whether or not a specification should be followed for its popularity, even though it limits innovation.