[akvadrako]

I agree with that totally.

Put another way, the problem with having a "software spec" is that you already have the "software which is a spec" and now you have 2 specs.

Or a 3rd way, figuring out the right interface for 2 components is at least 50% of the work when writing software. So, spec writing is like programming. And you wouldn't want to program by committee, would you?

This is one thing Amazon got right - having small internal departments and interacting like separate companies.

[Denzel]

Software is not the spec, it's an implementation... of which there are many implementations that satisfy one spec.

Spec writing is not like programming, and if it becomes like programming, then you're doing it wrong.

Specs are meant to constrain the visible solution space by defining the problem sufficiently.

To put it in programming language terms: a spec is declarative not imperative.

[akvadrako]

I guess you have never heard of declarative programming, design by contract or logical programming, which explicitly does constrain the visible solution space by defining the problem sufficiently.

Though imperative programming looks at the problem from another angle which is closer to execution details, it's not fundamentally different. A smart compiler/interpreter may completely ignore those details as long as it produces the right output, as specified by the spec. That spec being the code.

This is obvious when you see that one style of program can be converted to another style without losing the semantics.