Maintenance as a Learning Opportunity for the Software Journeyman

Posted on March 1, 2010


Warning: There might be typos 🙂

Last night (very late at night to my wife’s chagrin who wants me to go to bed like a normal… err, non-geek human being), I was responding to a poster’s question on JoelOnSoftware’s discussion forums. The question raised by this legitimately concerned young developer was regarding working in software maintenance: what sort of career path exists in software maintenance. You can see the whole thing here (including my unsanitized response):

When I was starting my work on software, I did also have the same questions. It should be a natural question for any developer eager to better himself in this demanding career of his choosing. Unless we are talking about extremely craptacular code within an equally craptacular of working environment, maintenance should not be seen as a dead-end. After all, for one to be a lead developer, or at least own a significant portion of a system under development, it is important to prove oneself. Doing maintenance in an existing piece of code (in particular one in which you originally participated) is an important vehicle for acquiring most, if not all, the skills required in a development journeyman’s travel.

My response (a bit sanitized version of the original is below). I hope someone finds it useful in his own professional journey.

Maintenance, is at the heart of the software industry. You never, ever, ever write a non-trivial piece of software and deliver it to your customer without ever having to deal with it again. Not unless it is trivial (and ergo, bug-free), or it is incredibly crappy-written (and you want to get away from it asap), or (in some cases) you are being dishonest, leaving your customer with a lemon.

You should look at this as your golden opportunity to understand the business your software operates on, to get well-versed in its life-cycle. More often than not, it doesn’t matter that you are a skilled developer if you suck at managing change in your code base and introducing new changes to it.

Software is not monolithic and impervious to change. It changes, it reacts, it has entropy. You should use this as your opportunity to shine. Learn how to negotiate changes with your customers; learn to project how much time or resources X or Y type of changes take; re-factor as you go; improve the code base; learn how to deliver on your promises; make those new lessons that you can apply every time you write new code.

And the thing is, even the most minuscule of bug fixes is new development. When you learn these things, that’s when you start become a software developer/engineer and not just a coder (however brilliant your coding might be.)

With all things being equal, if you are talented and responsible, you will never, ever walk away from a software product upon completion.

Now, I’m just talking out of my gluteus maximus here. If the type of bug fixes you do are very simple (.ie. changing lines in JSP pages) without any say in negotiating or devising any fixes at all, then I can see your concern. You will not improve your skills there.

Also, if the existing code base is a hall of coding horrors, and all you do is fixing coding wtfs, then I could see your concern.

You want to, you need to work in good development environments, ideally aiming at using good software development practices. You will have to make an objective determination of whether there is room for learn in what you are doing or not.

The itch to do something new does not necessarily justifies leaving a solid job where you can learn to operate at any slice of a system’s life cycle (not just development.) Be very mindful of the career choices you make – obviously, if you get a much better job offer somewhere else, go for it, but don’t just jumping from job to job every time you are asked to do maintenance.

Maintenance is part of a job well done, for any non-trivial system will have bugs. But a well-architected, well-developed non-trivial system will accommodate change.

CC by SA

Posted in: IT, learning, process, software