"ADRs just become a dump of opinions."

It's one of the more common reactions when introducing the architecture advice process. And honestly? It's not wrong.

But here's the thing: that's not a problem the advice process creates. It's a problem it makes visible.
>>>

Those opinions were always there. They just lived in meetings, rarely written down, usually processed through system 1 reactions that reinforced existing power structures and gave you the same outcome you always got. The loudest voice won, or the most senior person's preference quietly became "the decision."
>>>
When you write it in an ADR, something shifts. "I don't want X because I don't like working that way" suddenly sits there, visible, inviting a different kind of conversation. You can slow down. Move to system 2. Ask: what's the actual need behind this preference?
>>>
This is one of the things collaborative software design is fundamentally about: making implicit knowledge explicit. The opinions, the preferences, the emotions behind a technical stance, they don't disappear when you ignore them. They just go underground and shape decisions anyway, invisibly.
>>>
Because opinions aren't the problem. Opinions packed in pseudo-rational framing are. When someone says "this approach doesn't fit our architecture" but what they mean is "this makes my life harder and I'm worried about my team's workload", those are two very different conversations. One stays abstract. The other gets somewhere.
>>>

Separating information (the facts) from preferences (the opinions) is a move that only becomes possible when things are written down and transparent.

And if you can't have that conversation, if you can't dig into what someone's preference is really about, that's a different problem: the skill of having crucial conversations. No process fixes that for you.
>>>

The advice process doesn't give you worse decisions. It shows you the conversations you were never having.

#SoftwareArchitecture #DomainDrivenDesign #ArchitectureDecisionRecords #CollaborativeModelling #TeamTopologies