Software Architecture Guide (2019)

The problem is that bad architecture can be carried forward for a very long time at increasing cost.

The ability to differentiate good and bad architectures seems to be a lost art because to build this ability you need to have enough experience (e.g. the discussion in "The Mythical Man-Month"). Most software developers today have had no experience designing even a single system and many systems are often a random assortment of stuff thrown together by people without enough experience. What I call the "sort of works" architecture. It has big gaps but it sort of works and so there is continuous investment in trying to make it good, which is often a waste of time. You've lumped a bunch of stuff together to build something and now you're stuck with it.

AI as it is right now is probably a driver to make this worse because it makes it so much easier to throw random stuff together.

Take his advice with a grain... or perhaps a quarry's worth of salt. This guy has written plenty of books and articles about the "agile" dogma, but most crucially, nothing about any of the software that he wrote. These days, it's even more obvious as the contents of this page feel like something an LLM could've generated.

If you want a "software architecture guide", you'd be better off examining software written by the likes of Linus Torvalds, Richard Stallman, Brian Kernighan, Dennis Ritchie, etc.

In my 30+ years of SWE/SWA career this is the first time I can harvest the benefits of a well defined and exactly implemented architecture.

Thanks to LLMs.

Before LLMs even if the architecture principles were simple and clear, distilled into templates + codegens added for boilerplate / skeleton generation ... It was impossible to follow them on the long run. Devs tried their best, but on the long run everything eroded and there were no resources for refactoring.

Now, with coding agents, I was able to create a production grade app following a similar architecture to Presentation Domain Data Layering, from this article.

Now the codebase is 100% uniform both in content (code) and structure (files and folders). It's like being written by a single person. Finding a specific file takes a second with no cognitive load. Editing a file is straightforward since every file follows a specific template.

LLMs have benefits and drawbacks, and in this case their help is enormous.

"We create products and services that we are proud of"

This was one of the 3 core values in the best company I ever worked for. One I would never leave, if the region was not heading for a disaster.

Good architecture transcends the software: enables people to be their best, evolve the software to better match the reality of its reason for existence.

In an effective organization, people constantly exceed their own expectations. They debate alternatives, understanding the reality of momentum, but aiming for an infinitely long living product.

They identify the "main problem", find ways to best solve that.

A good architecture does not do much more than what's needed, but avoid unnecessary assumptions that would block future development.

It is vague, philosophical, pragmatic, challenging, rewarding.

The most powerful thing you can do in 2026: lint your architecture in a pre-commit check.

Agents & humans can’t commit, or stop work, unless they’ve passed all lint checks. Passing the linter requires complying with the architecture. Now architecture violations can’t creep in and entrench themselves - they have to be fixed upfront. Code review is free from worries about architecture too.

Start by having your agent install some import-linter rules. When you hit its limits, have your agent write a custom AST-based checker (a short python script will do) that can look for imports that violate your rules. Resist its attempts to add a `# noqa: imports` escape hatch, because future agents will gleefully abuse that and you’ll be back to human in the loop (ask me how I know!)

> This is what happens with poor internal quality. Progress is rapid initially, but as time goes on it gets harder to add new features. Even small changes require programmers to understand large areas of code, code that's difficult to understand. When they make changes, unexpected breakages occur, leading to long test times and defects that need to be fixed.

Seems familiar!

> Concentrating on high internal quality... is a rarer case, as it requires a skilled and disciplined team to make it happen. But we do occasionally see it.

Vibecoding vs. agentic coding. Same tools used different ways. Very different outcomes.

While these somewhat fuzzy definitions are hugely important (well, it says: "the important stuff, whatever that is", so by definition...), I have a hard time calling them "software architecture".

I'd like to suggest that at least some of the problems associated with the term, for example the pomposity, are rooted in the "separation from programming" that is not just a suggestion, but an unfortunate fact of architecture today.

And I would further suggest that we could improve the situation if we could actually express our architectures in our programs, in our programming languages. Then software architecture wouldn't just be "deeply intertwined with programming", as it must be, but actually be part of programming and part of the program.

And once the architecture becomes part of the program, it becomes part of our feedback loops. My experience is that feedback loops are a good antidote to pomposity and great for building/evolving systems.

To do that, though, we have to retreat from this idea that software architecture must be fuzzy, an idea that IMNSHO is just a cope for the current sad state of affairs. We have pretty good definitions of architecture (connectors and components, systems, architectural styles, etc.), let's start using them in earnest and in our programs.

If writing code is tactics and the end goal is strategy.

Is architecture operations?

Needs the [2019] suffix.