“The difference between good and bad architecture is the time you spend on it.”
– David Chipperfield

There is a specific kind of architect that worries me.
Not the junior one learning the ropes. Not the experienced one who double checks the consequences.
I mean the architect who is absolutely convinced they are right, and talks incessantly to prove it.

They stand by the whiteboard and speak in architecture keywords with complete certainty.
They speak in long monologues.
They lecture teams about principles and patterns.
They draw rectangles and service boundaries like they are solving the universe.

They explain. They justify. They narrate.
But they rarely validate.
No hesitation. No questions.

Everything sounds carefully thought out.
Except it is not.

Their confidence replaces evidence.
Their vocabulary replaces understanding.

This architect is dangerous precisely because they do not know they are dangerous.
They are convinced they are doing excellent work, yet the design is fragile.

The bad architect does not know they are bad because the system has not collapsed yet and the room is too polite to challenge them.

Bad architecture does not fail loudly.
It rots quietly.

You do not see the failure tomorrow. You see it six months later when:

  • Delivery slows with every new feature.
  • Teams avoid touching certain parts of the system because they are unclear, brittle or sacred.
  • Onboarding new developers feels like explaining an ancient religion.
  • The backlog fills with “refactor when we have time” tasks that never come.

The organisation loses momentum.
Morale sinks.
Decision-making becomes defensive instead of creative.
Progress feels like negotiation.

And the original architect never feels the pain.
They have already moved to another project, proudly presenting the same confident distance to a new audience.

This happens because architecture is one of the few professions where feedback is delayed and indirect.
If you write bad code, the compiler screams.
If you make a bad architectural decision, the system takes months to reveal the damage.

By the time consequences surface, no one connects them to the original design.

So the bad architect is not simply wrong.
They are insulated from reality.

Meanwhile, the good architect is the one who is never fully certain. They treat decisions as hypotheses.
They validate with prototypes, production data, and experience.
They measure how much pain a system creates, not how elegant a diagram looks.

The good architect feels responsible for consequences.
The bad one feels responsible for the picture.

If you want to avoid becoming the architect who does not know they are bad, train your instincts this way:

1. Assume your first solution is more complex than necessary.
2. Ask developers where the pain is. They already know.
3. Revisit decisions after real usage, not just workshops.
4. Judge architecture by how easy it is to change, not how pretty it looks.
5. Keep a healthy amount of doubt.. If you are too sure, you are likely missing something.

The good architect is not the loudest voice.
They are the one who reduces friction over time.

If you feel completely certain, pause. If you feel slightly unsure but you are listening and adjusting, continue.

Doubt is not weakness.
Doubt is intelligence. If you want to avoid being the bad architect, start doubting now.