Becoming a "maintenance developer"

Question

So I've kind of been getting angry about the current position I'm in, and I'd love to get other developers' input on this.

I've been at my current place of employment for about 11 months now. When I began, I was working on all new features. I basically worked on an entire new web project for the first 5-6 months I was here. After this, I was moved to more of a service oriented role (which was still great, all new stuff for me), and I was in this role for about the past 5-6 months. Here's where the problem comes in.

Basically, a couple of days ago I was made the support/maintenance guy. Now, we have an IT support team, so I'm not talking that kind of support, I'm talking more of a second level support guy (when the guys on the surface can't really get to the root of the issue), coupled with working on maintenance issues that have been lingering in the backlog for a while. To me, a developer with about 3 years of experience, this is kind of disheartening.

With the type of work place this is, I wouldn't be surprised if these support issues take up most of my days, and I barely make it to working on maintenance issues. Also, most of these support issues aren't even related to code, they are more or less just knowing the system architecture, working with making sure services are running/getting started properly, handling/fixing bad data, etc. I'm a developer, so this part sucks. Also, even when I do have time to work maintenance, these are basically just bug fixes/improving bad code, so this sucks as well, however at least it's related to coding.

Am I wrong for getting angry here? I don't want to really complain about it, but to be honest, I wasn't spoken to about this or anything, I was kind of just sent an e-mail letting me know I'm the guy for this type of thing, and that was that. The entire team took a few minutes to give me their "that sucks" talk, because they know how annoying it is to be on support for the type of work we do, so I know I'm not the only guy that knows it's not that great of an opportunity.

I'm just kind of on the fence about how to move forward. Obviously I'm just going to continue working for the time being, no point making a bad impression on anybody, but I'd like to know how you guys would approach this situation, or how you think I should be feeling about it/how you guys would feel.

Answer 1

You can look at this as either a as time in limbo; or you can turn it into an opportunity to grow.

The core idea of being a maintenance developer is to put yourself out of a job. Each time you have to fix something; take the time to understand the problem well enough so that your solution (which could come a few weeks after you put out the fire) means you (nor any other living soul) will ever have to solve that problem again.

Since it's a legacy system you're supporting, you can usually get a way with some solutions that wouldn't be "ok" for mainline products; you can use cron to periodically restart buggy services; You can hard-code exceptional logic for particular customers since the number of customers using that product won't increase.

Another part of it is extracting useful knowledge out of the system; You probably don't want to do this, it's not very much fun; but by documenting what the working system does (even if it does it wrong), you can make the task of mantaining that portion of the application an order of magnitude easier (ten minutes to read two paragraphs that explain a module, instead of three days reading the module code). Better yet, this same documentation can be used to implement the functionality in the mainline product, so you can stop supporting the legacy system altogether (for that feature, at least).

If you're the "go to guy" for a project, even if that's legacy maintenance, you probably (or at very least, you should) have considerable latitude to approach problems in your own way. That might mean rewriting sections in your favorite language or platform, suggesting workarounds instead of solutions, or just responding to issues with "wont fix, use supported products".

---

Edit: You might be misinterpreting your boss's intent; Maintenance requires a different set of skills from other parts of the development cycle; He might be putting you on a job because he thinks, out of all of the people he has available, you are the best for this role; not because he thinks you're not skillful enough for something else.

Maintenance requires a focus on reading code, more than any other role you might have. If you are good at reading, you will be good at maintenance. There are lots of developers, even ones of many more years experience, that just don't have the knack for reading other people's code (or worse, their own), even if they are brilliant at other things.

When you put yourself out of the job of maintenance, you aren't 'convincing management that you would be good enough to do something more important', you are literally taking the work of maintenance away from the living. When you stop doing that job, it's because there's nothing left to do. All problems are solved, either because they have been migrated out of the legacy application, because manual tasks are now automated, or you have convinced the customer that they don't want or need it and never will. If your boss interprets that as 'he's good at this, better keep him here', doing nothing at all, then he is a fool.

Answer 2

Being a maintenance developer != being left on the bench. Maintenance dev work can be some of the most frustrating, painful and annoying work in the world as you fix the weird issues the original developer missed.

It can also be some of the most rewarding, both personally and professionally, and educational work you can do. If you can take out a bug that's existed in the system for 6 months+ and has a direct knock on effect to 10% of the customer base your bosses will love you, 10% of the customer base will love you as well. By improving software incrementally and fixing bugs that take a week to track down effectively you'll be increasing your knowledge of not just that system, but what bugs that you can potentially see under specific conditions, and then you take it on board and become a better developer.

I love creating systems anew, but most of the tricks in my programming bag came from doing maintenance work and come in handy more times than I care to think.

Answer 3

Don't knock it. I've done plenty of time as a maintenance programmer. If the product is interesting and the other developers any good, you might learn something. And if they're bad, you'll learn what makes code unmaintainable, and you can use that experience when you're writing your own code. And after a while there, you'll be the guy they turn to when they need to know something about the code, because you'll know all of it, not just somebody's little silo.

And after you've learned your way around the code, you'll know which parts need refactoring and can propose projects to do so, which of course you'll be perfectly poised to lead.

Answer 4

It's worth noting that the role of maintenance engineer is not one, in a smart organization, given to someone because they're not good enough for something else... it's given to them because they ARE good enough to handle the particular role. Keeping existing systems up and running is an extremely important role and, depending on the company, many millions of dollars can balance on the tip of said engineer(s) doing their job well.

That being said, while most managers will intuitively understand that the role needs a skilled individual to handle it, most don't recognize the achievements of said programmers, and it can be hard to get recognition for your work. It's entirely too easy to be put in the role because you are skilled, and them forgotten about as raises and promotions are handed out later... because the sign of you doing a great job in your role is that nobody notices that you're doing a great job in your role.

It's possible to fight for the recognition you think you deserve for fulfilling the role, but I'm not entirely sure it's worth the large effort involved. Instead, I'd recommend discussing with your manager the concept of (as others have mentioned) rotating the role through the various developers available for it. If possible, have at least one person in the role full time and one person part time. The part timer can learn about the systems and what's involved in maintaining them from the full timer. When it's time to rotate, the part timer can take over as full timer, and a new person comes in as part timer (and learns from the now full timer).

If it makes you feel any better, the people in Ops are in the same position... the sign of a great Ops person is that nobody notices how well they do their job. Only, for an Ops person, they can't really rotate out because it IS their primary role. I'm a big fan of always praising the Ops people I work with, publicly and vocally, because dev is one of the few groups that can see how much better they make everyone else's lives.

That tangent aside... if you do rotate the position of maintenance, the next time you come into the role make sure to give the people before you their chops if you see they did things that make your life easier now that you're back in the role... do so publicly and vocally.

Answer 5

The constructive approach recommended by the other commenters is very good. As Token pointed out, you have a lot of leeway in that kind of position so long as the problems get solved and you don't break anything.

If you find that you can automate common solutions, or prevent them, you can buy yourself a lot of free time - and if the bosses' expectations of the demands on your time remain uninformed by this - to do other kinds of work that you enjoy more or that you think would be more productive for the company. My first "programming" job turned out to be a data-entry job, but I quickly discovered that a lot of the data entry was scriptable, and later, that it could be generated. I freed up about 7/8ths of my time, and used it to re-write the data entry system from scratch, including in it all the scripts and generators and more efficient UIs. It was a dead-end government job anyway, but the experience turned out to be invaluable.

Answer 6

Talk to you manager about rotating developers into the position (say on a monthly cycle or something). If everyone knows that it sucks then everyone will understand why the work is being distributed around the whole team. Maybe in talking to your manager you'll find out that this is already the case, and you've just gotten rotated in.

Answer 7

You need to ask why you were put in a role everyone thinks sucks. If your manager has half a brain, he'll know no one likes it and if he thought there are those that do, he could of at least asked. Find out how long this situation will last and if there are opportunities to move back to new development. You never know, you may walk into the office the next day and be given a brand new project. Stranger things have happened.