Maintenance means different things to different people, and comes about for different reasons.
- Worst case, the initial system was thrown together in a hurry, the initial team took credit for the whole thing. They followed the 80/20 rule, so while there might be a minimum viable product that can be sold, lots of customers need lots of fixes and small improvements. Many problems, but not much glory remain. You have the hardest job, and its thankless. I hope this is not your situation.
- Better case, you have shown that you are careful with your work and can be trusted to make changes to fielded product without breaking it. What problems remain are too hard for the people who hammered the original system together. Maybe they failed to build the system to last, and you are there, perhaps as their replacement, to set things right and rescue the customers, the project and the profits.
- Very likely case, 60% of projects costs come during maintenance. Perhaps it is timing, perhaps your organization segregates between new development and maintenance, but you are in the 3/5th majority because many of us do maintenance.
Here are a few things to try:
- Do a great job, have a great attitude, be an idea leader.
- As much as possible, work in teams, not alone.
- Learn newer languages.
- Learn newer platforms.
- Request to work on smaller programs, maybe even apply with smaller companies.
- Get skilled and get involved in documentation. When projects start, even in the post waterfall era, they need a lot of written coordination to road-map, document, evaluate, and clarify requirements.
- It is dangerous for projects to start in the hands of people who don't appreciate requirements management, estimation, and risk assessment, so learn and practice these skills as much as you can.
- Get more formal training or certifications. This may increase your status and make you a more attractive choice when teams for new development projects are formed.
- Start a company or some consulting on the side. This give you creative outlet to target your favorite kind of work, and gives you a better appreciation of what it is like to start with no code or documentation.
- Get closer to your boss and to people who plan new projects.
- Conversely, if you are super close to testers and QA, their output is often the input to maintenance, so guess who your boss thinks you work really well with?
- Make as many friends, and win the respect of as many greenfield developers as you can.
- New developers are the can do people, so be cautious about any hint of criticism or negativity. Give them your ideas freely without blame or judgement. Your ideas need no introduction, just say them. Never say, we used to do it this way, or that doesn't work, try this. Never say, I don't know, but this might work. Just say the idea. Or better, show it.
- Find and take any opportunity to build a proof-of-concept that might turn into your new project.
- Watch out who assigns you work. Usually, it should be someone in your chain of command. If it is your peers, push back some of the time. If it is someone you supervise, there needs to be a good reason control is inverting. If it is QA or test, make sure it matters to your chain of command and is not scheduled in a way that delays work you promised earlier.
- Beware of perfection. New development is often reserved for fast people, even if they cross the eyes and don't dot the t's.
- Spend time learning and practicing early project skills appropriate to your line of development. This could include: creating source repositories, defining the build environment, configuring the constant integration server, working closely with the hardware team to bring up new boards with board support packages or writing power on self tests. It might even help to know how to work with purchasing to buy new development tools, training, and COTS hardware.
- Make sure you move on before your maintenance project is closed, perhaps by shopping your skills internally to team leads and maybe managers, or externally.
- Be fluent in every technology you know, and know a lot of technologies.
A maintenance role can be turned to your advantage in several ways.
- You can potentially work on every project your group or even company
- If new development and maintenance is separated, you can
potentially follow a less competitive leadership track. Lead on new
projects is highly coveted, but maintenance lead might be available to you
for the asking. If you have encouragement and mentoring to give, members of that team may appreciate it more.
- If the project is in maintenance, you are more likely to interface with customers. Handled wrong, this ends careers. Handled right, it gets positive attention outside development that is hard to find without being a manager.
Having said all this, I am the counter-example not the role model. Much of this perspective comes from experience and observation.
There are many new programs that still need to be written.
Be ready and you will be working on one surprisingly soon.