The first duty of architecture is clarity (Part 2)

2026-04-14T00:00:00.000Z

In my last post I wrote that the first duty of architecture is clarity.

In that article I argued that clarity is one of the most important factors for software teams. Poor design isn’t the only way in which teams become lost — there’s another that I’ve seen often: constantly chasing new ideas and the latest tools.

Modern software engineering produces a steady stream of books, papers, frameworks, architectural styles and tools. Many of them are interesting, many are valid, and some are genuine improvements.

But most software engineers are not working in a research environment. We are trying to ship a product where:

• Time is limited
• Teams are small
• Systems already exist
• Customers are waiting

Even revisiting classic software engineering literature can be a challenge. I was influenced early on by books like The Mythical Man-Month, and by authors such as Grady Booch, Ivar Jacobson and Barry Boehm. Their ideas have become part of how many of us think.

Those ideas endured because they were absorbed slowly and applied over many years.

Today the pace of change is much faster.

In my own day-to-day work over the last decade, the list of things I’ve needed to understand has steadily grown:

• Cloud platforms, AWS services, Azure
• CI/CD pipelines
• Containers and Docker
• DevOps practices
• Secure boot, PKI and TLS everywhere
• MQTT and IoT platforms such as AWS IoT
• RESTful APIs and service architectures
• Git and GitHub workflows
• Agile processes
• A new language standard every few years
• New toolsets, IDEs, compilers and libraries

And those are just the technologies I’ve happened to touch. There are many more.

None of these are bad ideas. Many of them are improvements. But each one adds cognitive load, and that load rarely replaces what came before — it sits on top of it.

Each shift brings:

• New terminology
• New abstractions
• New tooling
• New failure modes
• New things the team must learn before they can be productive again

Individually these changes may be improvements, but collectively they can destroy the shared mental model that a team depends on.

I have seen teams become unstable not because the technology was bad, but because the ground kept shifting underneath them. Teams spend more time learning than finishing the job at hand.

There is a difference between learning and chasing.

Good engineering organisations learn continuously but adopt selectively. They recognise that stability has value, and that every new idea carries a cognitive cost.

• Not every good idea needs to be implemented
• Not every new pattern needs to become architecture
• Not every paper needs to change the system
• Not every new process is the silver bullet it purports to be

Sometimes the most responsible decision is to keep the system understandable, the tools & processes stable and let the team focus on delivering value.

Innovation matters. But so does clarity.

And clarity is much harder to maintain than it is to lose.