[saltedmd5]

Thing is, the need to formally define "behaviour" like that is a symptom of poor organisational/team structure. If you have multi-discipline teams with end-to-end accountability for a complete product (or vertical slice of a product) then your "spec" can be replaced with a problem statement and all of a sudden people can start focusing on whether the output solves the problem rather than whether it satisfies some arbitrary behaviour.

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

[Denzel]

It's blindingly obvious that you've never worked in, worked on, or managed a successful large organization (say >500 people || >$1B mkt cap) or a successful large project (say >5k man-hours || >50 people || >$10M budget).

> whether the output solves the problem rather than whether it satisfies some arbitrary behaviour

The spec is considered the solution to the problem! It's not arbitrary in any sense of the word.

[saltedmd5]

Re: first paragraph - incorrect.

The problem with "specs" is that you don't know whether they solve the problem until the solution is implemented and shipped. And even then, you have no real way of knowing what's meat and what's cud. So lots of time, money and people are thrown at solutions that - at best - are wildly bloated or inefficient and - at worst - completely fail to address the actual problem at hand.

The _need_ for specs is - even in large organisations - typically down to misplaced accountability. When you decompose the problem space into small pieces and give development teams a high degree of problem-solving autonomy _and_ accountability for production, the organisational disconnects that lead to the "need" (or, rather, the ill-conceived desire) for burdensome process and specification largely go away.

This isn't witchcraft - it's progress. It works; and it works in large organisations. You haven't witnessed it, so you don't believe me. If/when you do, I'd be willing to bet you'll be converted as I was.

But I'm sure I've given you plenty of reasons to double down on your skepticism.

[Denzel]

> Re: first paragraph - incorrect.

Please, do detail.

> The problem with "specs" is that you don't know whether they solve the problem until the solution is implemented and shipped.

No. Good product management eliminates this risk. And that's what you're talking about: risk.

You can test a product, feature, anything, many different ways before you build an actual implementation.

That's basic product and risk management.

> And even then, you have no real way of knowing what's meat and what's cud.

Monitoring.

> When you decompose the problem space into small pieces and give development teams a high degree of problem-solving autonomy _and_ accountability for production

You just like... defined what a spec is... man.

> This isn't witchcraft - it's progress. It works; and it works in large organisations.

Please provide the proof to back this up. Otherwise it's a baselsss claim.

> You haven't witnessed it, so you don't believe me.

No, I've arrived at my beliefs through the data on this point.

And the fact of the matter is that 100+ successful companies that have shipped successful products/projects operate with specs across many different industries from pharmaceuticals to construction to aeronautics and so on and so forth.

If the data supported your conclusion, then I'd agree with it. But the data does not support your conclusion.