Main idea

Software went through a period where analysts specified and programmers produced code by the yard. One group thought, the other executed. That split has disappeared: a developer today takes a problem end to end — architecture, code, security, delivery, follow-up — and even architects separated from the rest of the team are becoming rare.

Nobody is asking for analyst-programmers to come back, and nobody argues that better software was written when thinking and execution lived in two different heads. The trade settled it through practice, without theory.

That precedent carries argumentative weight: the same cut line, moved from code to product, has to explain why it would escape the fate of the previous one. The burden of proof changes sides.

Why it matters

This turns an opinion about product organization into a verifiable historical question: the design / execution separation has already been tried at scale in the same sector, and it was abandoned.

It also provides a probable trajectory rather than a mere disagreement: splits of this kind recede when tooling reduces the cost of doing both.

Nuances and limits

A precedent is not a proof. Development had its own reasons for stitching the two halves back together — short cycles, continuous integration, the cost of rolling back — and nothing guarantees those reasons transpose to product.

And the abandonment wasn't total: architect, staff engineer and tech lead roles remain, with a share of design distinct from execution. What disappeared is the transmission belt, not all specialization.

Open questions

• Which technical conditions actually made it possible to stitch design and execution back together on the development side, and which of them exist today on the product side?