“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.
I was in the war room at 2 AM, staring to the aftermath of what was supposed to be our next evolutionary leap.
We pushed the final piece of our cloud migration at midnight.
By 12:07 AM, 60% of our customers couldn’t log in.
By 12:15 AM, the rollback plan failed because the servers it was meant to restore to didn’t even exist anymore.
Despite the thorough migration plan, the old system was gone … extinct in a single night, and our “evolved” architecture had nowhere to run.
We didn’t anticipate the blind spots, and the post-mortem read like a crime scene report where we were both the victim and the suspect.
That’s when I realised Darwin’s theory applied to software too: Software behaves like living organisms.
Show me an architecture no one questions,
and I’ll show you a system no one understands.
A few years back, I walked into a post-mortem where the architecture was being blamed for everything from latency spikes to the office coffee machine malfunctioning.
The architect? Well, he was calm. Unbothered. Certain.
“It’s not the design,” he said.
“The team just didn’t implement it properly.”
There it was: the dead giveaway. He wasn’t doubting the design. He was defending it like gospel.
Right then, I knew.
The most dangerous architect isn’t the one who lacks answers.
It’s the one who never asks questions.
If you’re an architect or becoming one, doubt isn’t your enemy.
It’s your sharpest tool.
A few years ago, I took a week off. First vacation in months. On day two, I got six Slack messages, three “urgent” calls, and by Wednesday, the team had spun up a new feature that killed the application’s performance like a toddler on an espresso overdose: fast, chaotic, and entirely unsupervised.
That’s when it hit me: I hadn’t built a system, I’d built a babysitting job.
errorless (adj)
Free from error, accurate, correct.
Being complete of its kind and without defect or blemish.
I stumbled lately onto a strange feeling: many of the architectures I review are overcomplicated, fragmented, full of flows jumping here and there.
And what makes it worse? The costs of development, the deployment, the running, the operations — just to keep the system alive — are astronomical.
Back in 2014, I was at a meeting with a prominent French bank about a challenging project. At the time, “low-code” was a fresh concept, and the bank aimed to build its own low-code IDE to let business analysts craft UIs and speed up delivery.
The team already knew each other from previous projects, so introductions were a formality. Our manager introduced everyone: “This elegant lady is the delivery manager, that serious gentleman is the team lead…”
When he got to me, the bank’s IT manager interrupted, winked, and joked, “The guy’s doing nothing!”
We laughed sincerely and moved on.
“I hate and categorically refuse quick wins”, I angrily yelled.
The managers in the meeting jumped. They weren’t used to seeing me lose my zen and calm temper so often.
“I have a huge ethical problem with this organisation’s culture of quick wins. We are adding more layers of band-aids before even healing the scares”, I continued.
Being an Architect is like being a conductor1 in an orchestra. You’re not playing all the instruments, but your job is to make sure everyone is in concert [pun intended] and that the result is harmonious.
I once saw Simon Rattle conducting 6 Berlin school orchestras playing Edvard Grieg’s Peer Gynt Suite. As a matter of fact, they never worked nor rehearsed together before. Their first play was awful and cacophonic, but after multiple corrections and rehearsals, Rattle transformed the final performance into a beautiful and majestical piece.
After a heavy lunch break with a team, Dorian, one (among others) young and competent developer, enthusiastically asked me: “How does someone become an Architect, and what’s the path to follow and what to learn to be one?”
I wasn’t asked this question for the first time, and to be honest, I was never able to answer it properly.