I have spent the first decade of my professional life as a maintenance programmer.
What this means is that most of my job has consisted of fixing bugs, and improving the scalability of old, but often used software. This experience has given me some degree of insight into some patterns lead to scalable and maintainable software, in comparison to patterns that cost weeks, months or years of the maintenance programmers lives who come after every successful product.
I'd like to and talk about the psychology of maintenance programming and some of its unique challenges, and share a few patterns for having easier to maintain architecture, that can prevent significant suffering down the line.
Why does Maintenance Programming feel bad?
Most of us prefer to write our own code than maintain code written by other people. I think that the general consensus is that this is primarily ego-motivated, as in, we feel more tied to the success of code we have written because of a sense of personal ownership.
This satisfactorily explains why green-fields work feels good, but it does not explain why most of us developers have an aversion to maintenance programming roles. I offer the following idea:
Maintenance programming feels bad because of the anxiety that comes from uncertainty. When given a task to extend some piece of code that somebody else has written, new programmers will have a great deal of uncertainty about how the existing code works. This means that they will also be uncertain as to the impact any changes they make might have, and how long it could take them to solve whatever problem it is that they have been tasked with.
The uncertainty developers will face over and over again whilst working on maintenance programming tasks is a fierce psychological barrier to new developers, that are generally used to having their success in their coding tasks guided by tutorials and examples.
This is made even worse given that maintenance programming often involves failure. To fix a complex issue may require having a greater understanding of the code than the programmers that initially wrote it.
Beginner programmers learn by following tutorials and solving problems where the solution is already well-known. They are not necessarily emotionally equipped to face the uncertainty of fixing code that other people.
So our first encounters with maintenance programming feel bad. Why bother getting good at something that feels bad?
Why bother getting good at something that feels bad?
It's because you'll be valuable. The trouble with green-fields development is that you can not be certain that the work you are doing is ever going to be used. Given that being part of something bigger than yourself is an important factor in happiness, it is important for our mental health that we work on things that are meaningful, and a project that is thrown into the bin is certainly not that.
The joy of building something new can become ash in our mouths when the project is binned or the product fails. This is quite unlike maintenance programming where the value is already guaranteed. Maintenance programming is generally driven by the demands of existing users and customers, which guarantees that the product that you are enhancing is valued, used and appreciated.
Maintenance programming can come with a high degree of job security. A programming that dedicates themselves to becoming an asset to a product in high demand is a programmer that is quite challenging to replace. Whilst there are many programmers that can build a website from scratch, there are far fewer programmers that can be given the stack-trace for an exception and determine both what the error actually means and the cause.
Become a maintenance programmer and you are sure to be doing work of value, no matter how painful it may be.