Skip to main content

Which decision matters

Your team argues every architectural decision at the same intensity, and the expensive ones get no more time.

Where it goes wrong

Cheap and expensive decisions do not sort by category, so from inside an argument they look alike. Moving a codebase between languages is genuinely cheap now, though never as cheap as the headline ports suggest. Choosing what the rest of the system treats as true is as expensive as it has always been.

What decides the cost is how much of other people's work will sit on top of the decision once it is made. Everybody reaches for code volume instead, which predicts almost nothing.

How I'd handle it

My test is who has to move. A decision stays cheap while reversing it is yours alone to do. It turns expensive the moment reversing it means other people change what they already built, because their cadence is not yours and no tooling changes that.

I run that test over the whole list before anyone digs in, and put the hours into the few that fail it. The rest can be settled quickly and revisited when there is evidence.

Where I've done this

Band

Two of the decisions in front of Band looked equally weighty and were not. One was a build target, which can be added later without changing a line of the source. The other was a boundary both SDKs would build on top of, growing more expensive every week it stayed open. Separating those two was worth more than settling either of them quickly.

Sunbit

The argument at Sunbit looked like it was about Kafka and Kotlin. What was actually being decided was which system held the authoritative record, and that binds every consumer built afterwards. It is the same class of decision as the one in front of Band, in a completely different stack.

Recognize this on your team?

Let's talk
All decisions