Understanding maintainability is hugely important for any maintenance team. Although the financial affect of bad maintainability is difficult to estimate, it is clear that maintenance problems will cause significant increases in the development costs after the product is released. In this post, I will shortly discuss how maintainability is built and give some instructions for developers.
Traditionally people tend to think that maintenance is just fixing problems when they occur. In reality, at least in our experience, most of the maintenance effort goes into adding new features. Therefore, better maintainability is not just about fixing problems faster and easier, but also about adding to the business value of the product with smaller investments.
Maintainability is a notoriously difficult to define. One can find numerous different definitions for it in the literature, but none of them have been commonly agreed upon. In fact, I argue that there cannot be a definition that is both conclusive and measurable at the same time. This is because maintainability has a hint of subjectivity in its very core.
The ease of maintenance
Most common form for the definition of maintainability is quite simply “the ease of maintenance”. It’s actually very intuitive – almost a self-evident. The problem here is that we cannot objectively measure the ease of something so complex. It depends highly on the developer’s base knowledge, her experience in specific technologies, her understanding of the project, and the company culture.
So, why should we measure something that is difficult to set in mathematical form? It’s widely believed that one cannot control what one cannot measure. And, in a way, this is undoubtedly true. There are also many situations when it would be important to estimate how difficult a product is to maintain, before a developer is assigned to do the maintenance.
Luckily, there are plenty of sub-factors in maintainability that can be measured. Many researchers have suggested measurements for maintainability that are based on estimations of the sub-factors. The problem with this approach is that it doesn’t cover maintainability fully and does not reveal the underlying reasons when maintainability is compromised. One can spend a lifetime trying to find a perfect formula for maintainability, but never get anywhere with it.
As complex is the problem of measuring maintainability, as easy and intuitive is the workaround. To improve maintainability you do not improve maintainability. Not as a whole. Instead, you split the problem into smaller pieces, find the sub-factors that cause the maintainability challenges, and improve each aspect one by one. So, what are the sub-factors of maintainability? Numerous books have been written on the subject and it is not meaningful to list all the factors here. The main goal is to keep the source code readable, the structure intuitive, the test coverage high and documentation up-to-date. For more concrete ideas I recommend such books as “Clean Code” by Robert Martin or “Working Effectively With Legacy Code” by Michael Feathers. There are, of course, a lot of other great titles as well.
In the beginning of this post, I promised a few instructions. Before we get to them, I must warn you: as maintainability is not an exact science, I cannot give you concrete instructions. You have to adapt them to each project separately. And don’t just decide how you apply the instructions – also consider how you can measure and follow your progress during the project.
Consider maintenance from the beginning. Each technical decision affects the maintainability of a project. The longer it takes to correct bad decisions, the harder it becomes to get rid of the problems. Maintainability cannot be built into a project afterwards.
Define and monitor “done”. Definition of done is a well-known tool in the industry. But don’t make your DoD just a list of good practices. Define it so that you can follow it literally. This way it becomes more than just a guideline.
Automate processes. Scripts are handy when you have constantly re-occurring tasks. In fact, that’s what programming is all about. So automate your test routines, deployments and other must-have processes.
Share and store knowledge. Communication is the key to a successful software project. Understand the customer, understand other vendors and understand your colleagues. And once you have gathered the knowledge, store it in documentation. It’s very important for the maintenance team.
Test the code. Do I really have to emphasize this? Probably not. Just two things to say: try to break, not confirm, the program with your tests. And make the tests meaningful.
Refactor while making modifications. You are most familiar with a module when you are making a corrective or an incremental change. This is a good time to investigate if the structure of the module is up-to-date or not. If it’s not, refactor it.