Maintainability

This book is about software architecture. One of the definitions of architecture is the structure of a system or process. In our case, it’s the structure of a software system.

Architecture is designing this structure with a purpose. We’re consciously designing our software system to fulfill certain requirements. There are functional requirements that the software has to fulfill to create value for its users. Without functionality, software is worthless, because it produces no value.

There are also quality requirements (also called non-functional requirements) that the software should fulfill to be considered high quality by its users, developers, and stakeholders. One such quality requirement is maintainability.

What would you say if I told you that maintainability as a quality attribute, in a way, is more important than functionality and that we should design our software for maintainability over everything else? Once we have established maintainability...

What does maintainability even mean?

Before you write me off as a lunatic and start looking for options to return this book, let me explain what I mean by maintainability.

Maintainability is only one of the many quality requirements that potentially make up a software architecture. I asked ChatGPT for a list of quality requirements, and this is the result:

• Scalability
• Flexibility
• Maintainability
• Security
• Reliability
• Modularity
• Performance
• Interoperability
• Testability
• Cost-effectiveness

The list doesn’t end here.1

1 For some inspiration about software quality (which has been created by humans, and not a language model), have a look at https://quality.arc42.org/.

As software architects, we design our software to fulfill the quality requirements that are most important for the software. For a high-throughput trading application, we might focus on scalability and reliability. For an application dealing with personally...

Maintainability enables functionality

Now back to my claim that maintainability is more important than functionality from the beginning of this chapter.

If you ask a product person what’s most important in a software project, they’ll tell you that the value the software provides to its users is the most important thing. Software that doesn’t provide value to its users means that users don’t pay for it. And without paying users, we don’t have a working business model, which is the main measure of success in the business world.

So, our software needs to provide value. But it shouldn’t provide value at the cost of maintainability.2 Think about how much more efficient and joyful it is to add functionality to a software system that is easily changeable as compared to a software system where you have to fight your way through one line of code at a time! I’m pretty sure that you’ve worked on one of those software projects where...

Maintainability generates developer joy

As a developer, would you rather work on software where changes are easy or on software where changes are hard? Don’t answer; it’s a rhetorical question.

Aside from the direct influence on the cost of change, maintainability has another benefit: it makes developers happy (or, depending on the current project they’re working on, it at least makes them less sad).

The term I want to use to describe this happiness is developer joy. It’s also known as developer experience or developer enablement. Whatever we call it, it means that we provide the context developers need to do their work well.

Developer joy is directly related to developer productivity. In general, if developers are happy, they do better work. And if they do good work, they are happier. There’s a two-way correlation between developer joy and developer productivity:

Figure 1.2 – Developer joy influences developer...

Maintainability supports decision-making

When building a software system, we solve problems every day. For most problems we face, there is more than one solution. We have to make decisions to choose between those solutions.

Do we copy this bit of code for the new feature we’re building? Do we create our objects ourselves or do we use a dependency injection framework? Do we use an overloaded constructor to create this object, or do we create a builder?

Many of these decisions we don’t even make consciously. We just apply a pattern or principle we’ve used before that our intuition says will work in the current situation, as follows:

• We apply don’t repeat yourself (DRY) when we find code duplication
• We use dependency injection to make the code more testable
• We introduce a builder to make it simpler to create an object

If we take a look at these and many other well-known patterns, then what is their effect? In many cases, the main...

Maintaining maintainability

Alright, I assume that you believe me that maintainability positively influences developer joy, productivity, and decision-making. How do we know that the changes we make to our code base increase (or at least don’t decrease) maintainability? How do we manage maintainability over time?

The answer to that question is to create and maintain an architecture that makes it easy to create maintainable code. A good architecture makes it easy to navigate the code base. In an easily navigable code base, it’s a breeze to modify existing features or add new features. The dependencies between the components of our application are clear and not tangled. In summary, good architecture increases maintainability:

Figure 1.5 – Software architecture influences maintainability

By extension, a good architecture increases developer joy, developer productivity, developer retention, and decision-making. We could go on and find...