Drafts of the Mind #3

Hello folks, today we are going to continue with the third number of the series. In this post, I want to share my learnings about maintainable systems. As you know, I am currently reading Design Data-Intensive Applications, and in this series so far, I have shared some learnings while reading this book. Let's continue to share 😊

Nowadays, everyone knows that initializing an application costs less than maintaining it. So, if it is possible to build our system as maintainable, then obviously our cost will be less.

In here, I guess everyone can different understanding of what exactly cost is. On my side, as a developer, it can be a context switching cost while moving between applications, or it can be my stress level while trying to meet the deadline, or it can be my cognitive load while developing something in an application. However main idea is simple to understand, if we build maintainable systems, then our cost will be less. So, how exactly does a maintainable system look?

What is maintainability?

To explain a maintainable system, we must basically focus on three design principles:

• Operability
• Simplicity
• Evolvability

Let's investigate what is one by one:

Operability

Wikipedia's definition of operability looks like:

Operability is the ability to keep a piece of equipment, a system or a whole industrial installation in a safe and reliable functioning condition, according to pre-defined operational requirements.

As you can understand, operability refers to keeping the system running smoothly. If we build such a maintainable system, which means it can also be easily deployable, monitorable, configurable, and updateable or rollbackable.

Simplicity

When we start to develop an application from scratch, in the beginning, all piece of code blocks seems easy to understand. However, when our application becomes larger, we cannot easily understand the individual components or the entire system. It becomes very complex and difficult to understand. This complexity affects all developers who need to work on the system, even if they are senior. Because it leads to high stress levels, high cognitive load, missing the deadline, and so on.

Evolvability

Evolvability makes it easy for developers to make changes to the system in the future, adapting it for unexpected features.

While writing these sentences, I understand there is no way to build an evolvable system without simplicity. On the other hand, simplicity can exist without evolvability.

We can build as possible as simple a system using abstractions on a complex domain. But still, it doesn't mean the system can evolve easily. Especially if you are working on complex domains, each component will depend on the others. Due to these couplings, while implementing new requirements on one component, we could break others, even though the codebase looks simple. To avoid these kinds of problems, to make changes easily, we should write tests, and also we should document our system assumptions. But this way, every stakeholder can ensure the entire system works as expected after adding new features.

Now, I have finished the first chapter of the book. I hope you are enjoying my learning journey. See you next time 👋.
This article was written while listening to Spotify’s This Is Chopin playlist in the background.