Over the course of time, systems have become more complex to meet the user his requirements. At the same time, humans have not evolved that much. This leads to two challenges:
- Making a complex system easy to use for the user.
- Writing and maintaining such a complex system.
A nice example of this has been a hot topic for some time now: ‘Big Data’. As we kept on storing more and more information, it becomes harder and harder for humans to extract relevant or interesting information out of it. Showing all this information is something we don’t want as it is far more then human capacity. Instead we want to show only relevant and interesting information to such that a user can act upon it.
This sounds easy, where it not that different users want different things, and they consider different information to be relevant and interesting. Trying to satisfies everyone leads to an abundance of information shown, which is something we wanted to prevent. The only currently existing solution for this is building a highly configurable system to allow the user to specify what he wants to see.
This leads to an even more complex system, making it a lot harder for developer and maintainers. But this does not have to be the case. We have come a big way with building such systems, and learned a lot of things already.
A first step in keeping your software simple is by using good Object Oriented practices (assuming you are using an Object Oriented language). While this may sound obvious, it is actually much harder than you think. A good design is something that needs to be considered in each step along the way. It is easy to just add methods to functions and just pass around data, but these end up as utility classes that are being re-used in all different kinds of situations they were not designed to be used. But to match the different case some extra code is added.
Good Object Oriented practices should clearly specify the responsibility of the class, and avoid God or data classes. These practices are often broken as software grows, as more and more things are added the original design becomes inadequate. Keep the original design in mind, and change it when it no longer is useful.
When a class has clear and a strict responsibility it becomes much easier to think of the system as those classes and how they work together. This makes understanding it a lot easier, but what about maintenance? That as well will become easier as you don’t have to change a lot of things in many different classes. What still can go wrong are classes that a huge complexity themselves, often visible by the size of a method.
A good way to guard over the complexity of methods, and actually your code in general is using some static code analysis, and calculating the cyclomatic complexity of your code. If this is too high, you have a method that is hard to maintain as it does a lot of different things. Breaking it down in more focused methods helps overcoming this problem, and makes the system more maintainable.
An important note on keeping easy to maintain is writing clear and not just working code. Code conventions help with this, but even then choosing clear variable and method names make it easier to understand the code by just reading it. If a developer has to dig in a method to just know what it actually does, or if the name does not resemble what the method does than it is much hard to understand what is going on.
There is no need to proclaim that something is hard to maintain because it is a big and complicated system, The true reason why it is hard to maintain is because it is badly designed and poorly coded. Learn from it, what would have made it easier for you now? And start doing those things, and the future you and everyone else that will see your code will be thankful for it.