This post is an observation analysis result. It will put some light on why software is aging so rapidly. Maybe you will find some ideas to adapt in your projects, so they can live longer and be simple and smooth in maintenance :)

Table of Contents

What Constitutes The Maintenance Problem

Let’s start with some argumentation why the problem actually exists.

People Build Software

Each developer has a different way of implementing functionality. The created software is a snapshot of the developer’s construct at a certain point in time. This piece of code is a feature implementation.

Teams Are Not Forever

Teams produce multiple pieces of code that should work together. Over time, the development team may change, but the code remains. If the team decides to rewrite some areas, they just create new pieces of code.

Nobody Likes Brown-Field Projects

From time to time, developers will change jobs and join an existing project. Such a project has a history. It contains multiple pieces of code written by different people. Hopefully, the pieces are consistent.

Programming Paradigms Change

The programming paradigms change over time (e.g. Cloud development best patterns).

How We Can Mitigate The Maintenance Problem

Below I’ve listed some practices that helped me in the past. Of course, there is no silver bullet, but it’s worth trying :)

Generate Programs from Blueprints

What if we had a definition of the program on a higher level? For us humans, it’s much easier to understand graphs than plain text. We grasp the whole concept in the blink of an eye. Maintenance would be simpler if we could generate the code and program in such a way.

Simplify Solutions

From experience, simple solutions work. Complicated solutions raise more questions: “How does it work?”, “What will be the impact?”, and so on. Eventually, we end up with a mess of constraints everywhere. On top of that, we’re supposed to extend it with new features—insane.

Use super simple concepts when possible.

Stupid Simple Building Blocks

I found simple building blocks to be way better than sophisticated ones. Take serialization as an example. Let’s say we have a Person class with an avatar image. It’s simpler to serialize classes with primitive properties and base64-encoded images than to deal with subclasses for emails, phone numbers, and memory stream data for avatars.

Go for the low-hanging fruit ;)

Regression Tests

In the long run, we need to keep the contract between components valid. Otherwise, things break. I consider regression tests a quality gate. It can be unit tests or E2E tests. They should be fast and simply written.

Personally, BDD and functional tests don’t make much sense due to their maintenance complexity.

Final Words

At this point, you probably have some understanding of where this is going :) It’s the KISS Principle :)