Technical debt

There are meetings where everyone in the room knows the truth and nobody says it.

I’d been through the existing codebase. The designs were rough; the code behind them was worse, not catastrophically wrong, just badly built, in the way that happens when a team has been too busy to be honest with itself, and too stubborn to revisit the amateur choices it had made along the way.
I’d written it up. They’d seen my assessment and recommendations, but a new deck was better.

The meeting opened with a presentation: architecture diagrams, process flows, the kind of thing that takes real effort.
I didn’t say much.

Quality is subjective.  
Architecture is judgemental. 
So how on earth do we measure it?

Every architecture review, every design workshop, every committee meeting eventually hits the same wall. Someone asks: “But is this actually good?”

We pretend the answer lives in metrics. Response times. Availability. Coupling scores. Maturity models. Dashboards filled with comforting colours. We convince ourselves that if the numbers are green, the architecture is good.

That is the uncomfortable reality: half the time, those numbers are illusions. They tell part of the story.

I’ve witnessed perfectly green dashboards collapse the moment real business pressure appeared.