WHY?

Three codebases telling the same story differently

Nobody decides to drift. It accrues, one reasonable local decision at a time, until three clients quietly stop agreeing about what a thing is called, what it means, and what happens when you press it — and the product becomes a rumour that three codebases tell differently.

SDUX is an exoskeleton against exactly that. It forbids movement in the directions that cripple you, and it is worth wearing only because of how fast you can then run everywhere else. Three ideas hold it up.

The theory is the program

Peter Naur · Programming as Theory Building, 1985

A program is not its text. The program is a theory held by the people who built it — a grasp of how the code maps onto the world, why it is shaped this way, and which changes are in keeping with it. The text is a residue. When the people holding the theory leave, it dies, and no amount of reading the code revives it.

So the reasoning is written down on purpose, and the parts that cannot be inferred from the code are stated explicitly. When the theory changes the document changes — not when the code changes, but when the reasoning does. That matters more than ever now that half the contributors arrive cold every session and can read every file without knowing which decisions were weighed and turned down.

The theory is the program — illustrated
Missionaries, not mercenaries — illustrated

Missionaries, not mercenaries

Marty Cagan · Inspired

A mercenary ships the ticket. A missionary ships the feeling on the other side of the screen. That difference is an architectural question, not a motivational one: you cannot ask a team to care about a user they have been structurally prevented from seeing.

A product is a loop — someone hurts, you build, they feel something, you learn. Most stacks break it in the middle: the client knows what the user did but not why it mattered, the server knows what was requested but not what it felt like. SDUX closes the loop by making it the same object at every step. What a button does when you author it and what the client reports when someone presses it are one typed thing. So testing and analytics stop being features you build and become things you already have.

Name the catastrophe, or don't build it

George Fairbanks · Just Enough Software Architecture

Architecture is neither big-design-up-front nor absent. You name the risks that would actually kill the project, apply just enough structure to mitigate those, and consciously accept everything else.

Over-engineering is what happens when a system is treated as an intellectual puzzle instead of an open-ended product, so every brace here answers one question: which named catastrophe does this prevent? If there isn't one, it doesn't get built. And every brace is written down beside the price it charges — the trade is the part usually left out, and the part you most need before you copy the idea.

Name the catastrophe, or don't build it — illustrated