I recently started re-reading Bob Martin's Clean Architecture and found two other ideas I wanted to share. One of them (the topic of this article) is the dual nature of the way software developers provide value through code.
When you implement (or modify) a feature in your system you are creating value by altering or expanding its behavior. Most business managers (or even developers) believe that this is all there is to software development: Find people who know how to make machines behave in a specific way and pay them to do it. Create requirements and they will implement them.
There is, of course, another important quality of the software we often overlook: The architecture/design/shape of the system. If you've had the chance to work on projects with architectures of varying quality, you know the impact it can have in the future of development.
So, why is architecture so important?
Martin makes the case of the architecture of the system is more important than its behavior. His argument is that a system with good architecture, even if lacking in features, can be easily changed to accommodate any requirement. The opposite is not true: A system with bad architecture, even if doing all the required things for today's needs, is doomed to obsolescence.
And yes, software is soft, so you are right in thinking that all software can (technically) be changed. The problem happens when the costs of doing the changes exceed the benefits, leaving the system practically immutable. The reality is that most systems, sooner or later, become very difficult to change at least in part: Some classes or config values become so entangled that change becomes impractical.
A good architecture makes the difficulty of implementing a change proportional to its scope, not the type of change. An architecture that develops a strong preference over a specific type (or types) of change, and makes some others very difficult, will eventually make continuous development more difficult, that's why good architectures are usually shape/type-of-change agnostic and generalize well.
So, if it's such a bad thing, why does it happen?
I think it's a combination of factors:
- Most business managers don't have the technical expertise to assess the importance of good architecture. From their point of view, the only thing that matters is that the system does what it needs to do, no matter how it's written.
- Market pressure pushes developers into a train of thought that goes something like this: Ok, now we need to put these features into production before the competition. Later, when all this is done, we will have time to refactor everything into better shape. Spoiler alert: it never happens. Once the system hits production the demands and pressure only increase. The team is now responsible for ongoing development, maintenance, and operations!
What happens next is something that you might have experienced, no matter if you are from business or tech: The changes become harder and harder to implement and the project slows down to a crawl. The costs of running the project increase year by year and recruiting more people doesn't seem to fix it.
This is frustrating for everyone. Management feels like they are just providing a stream of changes with similar scope, but each time it takes longer to get them into production. Developers feel as if they are handed a stream of increasingly complex pieces to fit into a monster that becomes more complex and difficult to tame.
Ok, get it, but what can I do?
There is no easy answer, but in most successful teams, it goes something like this:
You need to remind yourself that you are the main stakeholder when it comes to the architecture and design of the system. Business managers are not equipped to evaluate the importance of the architecture, that's why they hired you! Your job is not only to make the system behave in the right way, but it's also to watch over the long-term quality of the system.
Also, people are willing to listen when the stakes are high. A system where the architecture comes last will eventually reach a point where changes are impossibly expensive. Talk to the other stakeholders and create the habit of balancing the development of new features, bug-fixing, and refactoring.
The reality is that at the end of the day, nobody but the development team really cares about the architecture of the system. So pick your fights, push back when needed and communicate the importance (and consequences) of keeping the system healthy.
I wish you luck.
