dev blog by stemos

Don't end up as a code maintainer!

Maintaining code is not very popular with developers. Martin Kleppmann writes in "Designing Data-Intensive Applications":

Yet, unfortunately, many people working on software systems dislike maintenance of so-called legacy systems—perhaps it involves fixing other people’s mistakes, or working with platforms that are now outdated, or systems that were forced to do things they were never intended for. Every legacy system is unpleasant in its own way, and so it is difficult to give general recommendations for dealing with them.

Now, even if you don't like it, maintenance is a chore you have to do from time to time as a developer. However, consider that you end up in a situation where you need to decide whether you want to do maintenance as your main work task. Should you do it?1

TL,DR: The answer is almost always "NO".

Let me start with an example. Imagine it is 2012 and your company has a product that consists of an on-premise Java EE-based monolith server and an Eclipse RCP-based client. The leadership team figures out that the future lies in subscription-based software hosted in the cloud. A new project is started to create a modern web application on AWS. Initially, all developers work on both projects. After a while, the management realizes that this approach does not work efficiently because of the lack of focus. They call for volunteers that maintain the old product full-time stressing its importance to company. Which project would you choose? If you are a younger dev, I guess am convinced your answer is the new thing. However, let's imagine you have second thoughts. Naturally, not everybody can work on the new thing. The legacy product is still responsible for 100% of the revenue and the new product will only be released in 2 years. Somebody has to maintain it. Customers are also expecting new features. Finally, you decide to be a brave maintainer. And you do an awesome job. Besides the paltry investment in the legacy product, you are able to keep its market share, tremendously improve its quality and even add some cool new features. Management should be extremely grateful, right? The chances are high they are not. Don't blame them. Blame capitalism. I'm serious. Investors expect growth and the purpose of the new product is to generate it. Thus, management will focus on the new product and your heroic efforts will go largely unnoticed. The seaman analogy to your situation is that

you work on a sinking ship in a backwater trying to make the sinking a little bit more graceful whereas your captain is already steering a fancy new ship on the ocean.

Don't get me wrong. It has also benefits to maintain a legacy product. All the bug fixing, code reading, and reasoning about other people's decisions will likely make you a better developer. If the product you maintain uses a technology that is in high demand, it could even pay off financially. And as the focus of (product) managers is on the new product, you could have more autonomy than you had working on the new stuff. However, in the most cases the benefits don't outweigh the downsides. Eventually, the old product will reach its end-of-life. And then? You don't have deep knowledge about the new product. You don't know the background of the decisions made in the past. You are probably not well connected to all the folks who have started to work on the new project since your decision to be a brave maintainer. Also, if you apply to another company, you probably lack practical experience with newer technologies.

Thus, my advice is that you should never ever agree think carefully about the points above before agreeing to maintain a legacy product. IMO, it makes sense to work as a full-time maintainer for a limited amount of time (say 3 to 6 month). However, it is hard to get out of this "position" once you're in it.

Footnotes