Every time I hear about software maintenance as a distinct activity, I cringe. That’s because it is based on the outdated notion that first software is developed, then it is maintained. But that is not how software development works today. Software development does not have the two phases development and maintenance – it is a continuous process. Software maintenance is simply software development.
It is fairly common to come across the concept of software maintenance. Recently I have seen it in posts on LinkedIn (how developers leave if they have to do maintenance), in books (“it is well known that the majority of the cost of software is not in its initial development, but in its ongoing maintenance”), and in surveys (do you develop new features, or do you maintain existing features). But this is based on the false premise of the software project.
Project vs. Product
In the project model, you set out to develop a system. So you create a project, gather requirements, develop the software, and deliver the result. Any changes after this delivery are considered maintenance, be it changes to functionality or bug fixes. This is how I was taught software development works when I went to university a long time ago.
There are two big problems with the project view of software development. The first is that it is almost impossible to decide how the system should work before you try it. As soon as you start using the system, you learn more about how it should work. This inevitably leads to changed requirements. Secondly, once the system works, you start to think of additional uses for it. In other words, the problem you are solving is open-ended (expanding uses), rather than clearly defined. In a sense, you are never finished, because what you want the system to do keeps expanding. This may seem counterintuitive, but for all systems I have worked on, I have been surprised at how we never ran out of features to add. The expansion is also fractal – you add new big features, but you also keep tweaking and expanding the behavior of existing features.
So, the project model (build the system once and for all, the rest is maintenance) does not match how software systems evolve.
A better model for software development is the product model. Here you consider the software system to be a product that is continually developed. There is a permanent team of developers working on the system, and you continuously add features to it. In the product model it doesn’t make sense to distinguish between development and maintenance, because you are constantly changing and developing the system. This includes fixing bugs. Over my career in software development, I have seen a shift from project to product. This makes sense, since the product model aligns much better with how systems are used.
There are other advantages with the product model too. The developers working on the product stay with the same product. They see how it is used, and understand how it has evolved. In the project model it is more common to have people develop the initial system, then leave for the next project. They don’t have to live with the decisions they made, and they don’t get the benefit of learning how the customers are using the system.
Happily, many (or most) companies have realized that the product model is better than the project model for software development. This means that it doesn’t make sense to talk about software maintenance. Changing and improving the systems is software development.
What About “Pure” Maintenance?
Maintenance in the traditional sense includes lubricating moving parts, changing filters, or mending broken pieces (like sewing on a loose button). In software, fixing bugs is the equivalent of repairing broken parts. What about preventing wear and tear? Well, in this sense software is the opposite of physical objects. The more you use it (if by that we also include bug fixing), the better it gets. I like this quote:
“Hardware eventually fails. Software eventually works.” – Michael Hartung
However, if you consider that the environment the program works in can change (library or OS upgrades for example), then you could compare this to handling wear and tear.
There are systems that are maintained only in this sense: fixing bugs, and making sure that it can keep running. But I would argue that this is a very small part of all software development work being done. Furthermore, when it comes to fixing bugs, there can be ambiguity. Is this really a bug, or is it in fact a request for new functionality? And why fix the bug at all, if it has worked up until now, and the only objective is to keep the system running. So, in some sense, this form of maintenance is also just ordinary software development.
Conclusion
In any form of software development, you always have to read and understand existing code, even when you mostly add new features. As the system grows, this becomes even more common. Newly written code becomes “legacy” very quickly. Furthermore, you always have to fix bugs. So, let’s stop talking about software maintenance is if it were a separate activity. It is not. It is just software development.
Read More
Augustine Fleishman