Writing
The Part That Isn't on the Diagram
Architecture patterns get the attention. What decides how a project goes is gathering information, clarity, staying organized, and people.
When a system turns out well, the credit goes to the architecture. The modular monolith held. The hexagonal boundaries paid off. The events decoupled what needed decoupling.
It’s a comfortable story. It is rarely the whole one.
By the time a pattern is on the table, the important work is either done or missing. Someone has asked what the system is for, or nobody has. Someone knows who decides, which deadline is real, and which constraint is only a habit. Or the team is drawing boxes around a problem nobody has described yet.
So the job starts earlier, and it looks plainer.
Gathering information. Reading what already exists. Asking the question that sounds too basic. Talking to the person who will operate the thing.
Clarity. Saying what you found in words the whole room agrees on, and keeping it short.
Staying organized. Writing down what was decided and why, so the same conversation doesn’t have to happen again.
And people. Every one of those steps runs through somebody, and what they tell you depends on whether they think you’re listening.
None of it shows up on the diagram. It shows up in whether the diagram is right.
The patterns still matter, and I’ll keep writing about them. They’re just the part you can look up.