A “spec” is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate.

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

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.

So please don’t bother talking about specs. Real standards grow up
_despite_ specs, not thanks to them.

Linus

You might wonder whether the Linux operating system provides evidence that offshoring can pay off. I had often wondered about this point myself, so I put the question to Linus Torvalds, founder of the Linux project. Torvalds replied that the two models of software development aren’t comparable:

I don’t think the Linux model works for offshoring in the commercial sense, or really ends up even being very relevant. The problem ends up being communication and the mental model pretty inherent in offshoring.

My belief is that when you say “offshoring,” you very much mean “control the project on one shore, work on the other.” That is, the implication of the offshore work being “subservient” is very much there in the notion of offshoring.

In contrast, the Linux model (and open-source in general) is that there’s no one-sided control, and that when work gets done overseas, it gets done because it makes sense to them, not to “us.” There’s no control of one end over the other–both shores do what they want to do. The fact that makes it all work out is that, in the end, everybody tends to have somewhat overlapping goals.

— Norman Matloff, “Offshoring: What Can Go Wrong?,” IT Professional, vol. 07, no. 4, pp. 39-45, Jul/Aug, 2005