Software Architecture Guide (2019)
martinfowler.com
Software Architecture Guide (2019)
1–10 of 39 posts
Re: Software Architecture Guide (2019)
#2The 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.
Re: Software Architecture Guide (2019)
#3Needs the [2019] suffix.
Re: Software Architecture Guide (2019)
#4The 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 ass…
> 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.
My experience has been the opposite: affordable slop makes me way more conscious about architecture because bad patterns become useless exponentially quicker.
Re: Software Architecture Guide (2019)
#5The 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 ass…
Well it can go in both directions I guess. How to design a system well for the long term is definitely in the training data, and I‘m regularly very content with the suggestions that SOTA coding agents make when asked for it.
Re: Software Architecture Guide (2019)
#6The 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 ass…
So what would be a good architecture? How would I recognize it if I stumbled against it?
My own inclinations here are that it would be good to have as few different technologies as possible. To run things on as few different machines as possible and to have automated tests for everything. The thing is that as soon as there are multiple technologies you get to have different people specializing in them and it is always the communications between those that becomes painful. The automated tests are there to prevent fear of change setting in. I think I am kind of advocating what is called a 'big ball of mud' but that I want it to be a transparent ball of mud because of automated testing. I guess what I am saying is that I distrust most developments in so-called application architecture of the last few decades except automated tests. In particular, I think frameworks and microservices are mostly just bad.
Re: Software Architecture Guide (2019)
#7In 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.
Re: Software Architecture Guide (2019)
#8If writing code is tactics and the end goal is strategy.
Is architecture operations?
Re: Software Architecture Guide (2019)
#9In 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 erode…
Something I recently realized is that the fastest and easiest way to use coding agents is if you apply them to problems where there is just one, obvious solution.
This absolutely relates to architecture. If your system is designed such that any given feature fits in an obvious place, using obvious patterns, with obvious ways to test it... 90% of the time a coding agent will be able to do exactly the right thing from a single, short prompt.
This also makes code review so much less taxing - if the solution is obvious, reviewing and checking that the agent followed that obvious path takes much less time than if you're trying to untangle something a lot more complicated.
Re: Software Architecture Guide (2019)
#10The 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 ass…
So what would be a good architecture? How would I recognize it if I stumbled against it? My own inclinations here are that it would be good to have as few different technologies as possible. To run things on as few different machines as possible and to have automated tests for everything. The thing is that as soon as there are multiple technologies you get to have different people specializing in them and it is alway…
In an existing system some combination of these attributes:
- High quality (e.g. low number of issues hit by customers, resilient to failures, efficient, secure etc.)
- Easy to maintain (well organized, broken down in a sensible way into components or layers)
- Easy to extend/adapt to future requirements (i.e. the designer was able to anticipate the likely direction of the system and account for that in the design)
Automated testing feels a bit orthogonal to me but a system that is easy to test is likely one with a better architecture. It's not strictly part of what I'd call architecture.
Less different technologies - YES!
Runs on fewer machines is a sign of an efficient/performant design. Less well designed systems exhibit bloat that is often made up for by running on more machines.