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