The Maintenance Problem
Why it is easy to build and hard to maintain software?
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 :)
Let’s start with some argumentation why the problem actually exists.
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 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.
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.
The programming paradigms change over time (e.g. Cloud development best patterns).
Below I’ve listed some practices that helped me in the past. Of course, there is no silver bullet, but it’s worth trying :)
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.
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.
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 ;)
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.
At this point, you probably have some understanding of where this is going :) It’s the KISS Principle :)