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. 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 that helped me in the past. Of course there is no silver bullet, but its worth trying :)

Generate programs from blueprints

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

Simplify solutions

From the experience, simple solutions work. Complicated solutions require more thinking “How it works?” and “What will be the impact?” and a bunch of similar questions. finally, we end up with a lot of constraints added everywhere. On top of that, we are supposed to extend out new features - insane.

Use super simple concepts when possible.

Stupid simple building blocks

I found simple building blocks to be way better than more sophisticated ones. Let’s take serialization. As an example, let’s say we have a personal class with an avatar image that we want to serialize. It’s simpler to serialize classes with primitive properties and base64 encoded images than keeping emails, phone numbers and other data as sub-classes and avatars as memory stream data.

Go for the low-hanging fruit ;)

Regression tests

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

For me, BDD and functional tests don’t make much sense because of maintenance difficulties in those tests.

Final words

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