Came across a link on kerneltrap regarding Linus's opinions of specs (http://kerneltrap.org/node/5725). The salient points he made are (and I quote):

"So there's two MAJOR reasons to avoid specs:

- they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None.

It's like real science: if you have a theory that doesn't match experiments, it doesn't matter _how_ much you like that theory. It's wrong. You can use it as an approximation, but you MUST keep in mind that it's an approximation.

- specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP.

The classic example of this is the OSI network model protocols. Classic spec-design, which had absolutely _zero_ relevance for the real world. We still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them.

And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software."

I happen to agree with these points. Evolutionary design and just making shit up as you go along isn't always so bad. It's the prime technique employed by Mother Nature herself and as we are an output of this process I don't see that fundamentally we, and what we do as humans, can be all that different.

Of course it can be argued that there will be many wrong turns, backwards stances and abortive ideas, but that's not important. The process itself falls prey to the law of large numbers. On a small scale we'll screw up, but over time if we work hard and smart, we'll get there. It gives us as people agility.

As Patton said "A good plan executed right now is better then the perfect plan executed next week."