Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.

However, there are things you can do to maybe make your life and future a bit more livable. I'd start with mentally breaking down the current project into modules, and then asking for permission to refactor, or rewrite those, one at a time, in accordance with more stringent coding standards. Make sure to write plenty of tests around anything you write, or improve.

This should see your work life improving slowly and steadily, as this approach will get your more familiar with the application, improve the readability of parts of it, and make bugs less common.

How to sell this to the owner/leader/boss will vary widely depending on the corporate structure and personalities involved. But if this really is unbearable for you, and you get no power to improve things, then finding a different kind of job might be for the better.

In general it seems like consultants will in general work on more recent code, and they do have more flexibility in being moved from one project to another, or to focus primarily on new(ish) applications.

However, legacy code will always be a part of your chosen profession, and you are going to have to learn to get along with it, and live with that fact.

Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun.

It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time.

A good manager will realize that they are burning your usefulness and willingness to work for them and will try to arrange for you to spend some time on different projects but this is no guarantee! If you are the only developer who can do this job you just might be stuck there.

To help this course of action it is a good idea to prepare some thing that you would like to spend your time on: those projects you started, maybe some other project or even a course to improve your skills. This will help turn a request into a Plan.

A bad manager will resent you because "he complains about stupid things", this is unreasonable but you wouldn't be the first to receive pushback.

To prevent this, have a concrete list of things that make the job Not Fun: stupid bugs, repeat tickets, un-commented code. This turns a complaint into Feedback and will make your questions sound more reasonable.

My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?

No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that you started from scratch but you cannot expect every project to be this way. Sometimes, for a period of time, the business does not need new projects started from scratch ( that is not saying that they never will again ) and they just need to maintain the existing projects.

What you should do is take ownership of your current project. Forget about the fact that it is 6 years old and 5 other programmers worked on it. If it is messy and full of bugs then take the initiative to fix the project. You will certainly look better in the eyes of your manager if you successfully bring the project to a stable state instead of complaining about having to do work on this project and trying to have different work assigned to you.

You can always ask, but they can always say no, too.

Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit.

You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs.

Or you could argue for a new development of the product with better practises. But as long as the old project has paying users somebody has to maintain it and they chose you Pikachu.

You could argue to get more people to do what you are doing (Bus-factor) so that you can work on other projects as well. If these become more important than the legacy project those might become an out.

But again: As long as there are people paying your firm and in extension paying your bosses wages for this project, and your firm isn't inclined to give this up, somebody will have to fix the bugs.

You could quit and work as a freelancer as a last resort. There you can really pick the projects you are working on but be prepared to have to do some projects you don't really like to keep the lights on. Only the best and best-known can cherrypick what they do completely.

tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required.

One of the most important things in professional software development is collaboration on a shared codebase. Unless you're a rock star soloist, the codebase will always have a history, shaped by past and present colleagues – and possibly also yourself in the past.

As you've already mentioned, reading code is much more difficult than writing it – which is exactly why this skill is so important. It takes a lot of skill and patience to learn and understand the nooks and crannies of an existing project. It's easier – and granted, more pleasant for the developer – to start things anew, possibly even choosing the technologies and frameworks used.

Commercial software always serves a business purpose. This means that – unless you're only working with startups or marketing – software should have a reasonable life expectancy. The developers who go the extra mile to familiaze with existing solutions, and especially, existing business interests, are the ones who make themselves valueable – and often difficult to replace.

As you've pointed out, legacy code isn't always (ever?) easy to work with, bug-free or clean. What I'd suggest you to consider, is to turn things the other way around: Each impossible snippet of spaghetti copy-pasta is an opportunity for a great refactor with unit tests; each bug report is a chance to impress the business and the end users with impeccable customer service.

My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially.

I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding team should never be allowed to touch computers ever again. My supervisor is responsible for the other product, and it is also a disaster.

The chief benefit of working on these dumpster fires is that we are getting good solid lessons on how not to do things, and even with three years in industry you are learning something like this from the products you are working on.

So stop looking at your situation as something that you should not have to deal with, and instead look at it as how you are going to make your company's product better than it was.

As an easy first step, every time you have to puzzle out what a piece of code does, put comments in the code explaining exactly what the code is doing. It may not help you—although I find that it greatly helps me—but the next person to look at the code won't have to puzzle it out.

Lots of great answers already, but adding my £0.02.

Maintaining older software is more difficult than building something new, it's also a valuable skill in itself.

Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is something many employers, particularly in the enterprise world, actively look for.

If there is no documentation, then write some. If there are no automated tests, then work on refactoring the code so it's testable and write some tests. If the coding styles are all over the place, then research the recommended styles for the language or framework and work on refactoring the codebase to match the recommended coding style.

Gaining a reputation as being somebody who is happy to work with legacy code, and who does it well, can be as good for your career as working on greenfield projects with the new and shiny frameworks.

As time goes on, the amount of legacy code in production is only going to increase, and demand for developers who can look after it, fix bugs and add new features is going to increase along with it, as rewriting those applications with new tech is generally considered to be a bad idea for lots of good reasons.

Good luck!

Legacy maintenance builds the developer's desire for good practice

I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.

I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.

It has been my predominant experience that developers who write bad code are in one of two camps:

• Those who didn't know any better


• Those who think they are doing the right thing

The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.

Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.

The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.

This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.

What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.

As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.

Cleaning up after others

You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.

Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.

I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.

On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).

Addressing the issue

Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.

In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.

But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.

The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).

If you don't like what you're working on, then leave for another company. Programmers are in high demand.

Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to complain about it.

There is rarely much scope for changing your day to day work within a company, those things tend to be long term, and they are almost always inferior to simply finding another job doing something you want to be doing.

It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot handle. So a company of a different nature may be a solution.

But, you can view your situation in a different light.

If the software you are maintaining is bad, then fix it. If it is beyond fixing, explains to your supervisor why it is so, and propose a solution.

What you consider a bad situation, could be instead a chance to show your supervisor what you are capable of.

If your supervisor sees you in a positive light, you'd have a much better chance to get assigned to the projects you want to do, or persuade him/her to reassign you.

In my current 2-year contract job, I'm maintaining bad software like you. The original vendor is long gone and code quality is bad. My supervisor is reluctant to big changes as the company culture is very reserved and they hate taking risks. I presented the pros and cons of various options to fix the part I am working on, it took me lots of effort but I eventually won them over. A few months in, my supervisor is talking about offering me a permanent position.

Heroes rise from the occasion.

Put yourself in the other shoes
You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative?
This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project.

• Does he has another replacement?


• Does he has another project more attractive to your preferences that give you motivation, maybe a 50% of your time?.


• Can he give you green light to recreate some part of the project?

You don't know for certain.... so, yes, you have to talk to him. Not in a demanding way, no if you like the workplace. But you have to talk to him about your discomfort, because employees leaving is not a good result either, ... no company/manager get benefit for a developer resign. And you are not asking him more money, or less hours, or telecommute, or something that interfere with the company policies/resources. It's something about trying reorganize allocations of the team, it´s more 'doable'. And you are not getting fired for let him know about a discomfort. But the only one that can help to resolve your discomfort is him, if you want to stay there of course.

Ask him for a short private meeting.
Be relax, no angry emotions, no demanding tones.
This is a conversation with a team member that can help you find a solution to a discomfort.

Even if he does nothing for you, and nothing can be done. It´s not in your hands, you did what you could to be moved. Because if you say nothing and find a new job, in the moment you say to him, the first thing is going to tell you is 'I didn't now you felt this way, we could try to work this out'. When you leave a company for money, you ask a rise first, this is the same, before start to look for jobs, let them a chance to find a solution where both interests get satisfied. Think in a way that you get motivation at the same time you provide value to the team/client

There's a good chance you might benefit from hearing my story, so here goes.

I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a total loss despite the codebase being only a year and a half old at that point. I thought at the time I was looking at a three year old codebase and the company had a history of bad source control practices. In fact their source control use was kinda ok (it got better) and the product was made by big bang production.

I reported by analogy the foundation was cracked and the ground was unstable. In fact a total rewrite was required but it could not be afforded at that time and I knew it. We agreed by analogy that as it became necessary I would ram I-beams through the foundation to serve as pylons. Over the next decade as things broke or became unsustainable or the profiler located hotspots I replaced almost all the original architecture, to the point were now only a couple dozen lines remain. But now the I-beams themselves have cracked and been braced and the house-become-skycraper is showing its age and again become hard to work on and I dread teaching new programmers all that is required to add new tables to the database as no good examples remain. Every explanation for how things work has become a history lesson now.

I don't work on the product much anymore, but whenever a change needs to be made that breaks the rules of the architecture, I do it, not because only I can do it, but because I know essentially all the rules in my head and therefore can pick the way easiest to maintain the consequences thereof.

But only now do I have the experience to do actually to it right and design an architecture that can actually be maintained for twenty years or more. Some of the problems are bad decisions of the original architecture where I replaced the implementation with a work-nearly-alike retaining many of the same decisions. Some of the problems are my own bad decisions. And the industry has changed and we want to replace the fat-client architecture with a web architecture. You know what, now's the time. I don't have the full set of skills for a web architecture but I've got most of them and I know where to turn for the rest.

The choice really has to be yours, but you may have here the place to run I-beams through the foundation. If you choose to do so, you're gonna learn and become strong.

Make sure you know yourself before doing anything drastic

Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn to like maintaining legacy code. If you have a mentor, this would be a good thing to discuss with them. If you don't have a mentor, you should try to find one.

Unhappy = poor performance = career hit = time to change

Once you're sure it's not you, it's the job, then realize that you will only do your best work if you're happy, or at least satisfied with your job. If you are actively unhappy or hate your job, it's going to show in your work. This will hurt your career in the long run. So you're not doing yourself any favors staying in a situation that actively makes you unhappy (sometimes we don't have any choice, but if you do, and most of the time we do, then you need to make a change).

What should you do?

Tell your boss your preferences, and if your boss can't or won't honor them in a reasonable time frame, find a job that can and will. Note that almost no job (including if you're your own boss) will meet your preferences 100% of the time; that's just life. But a good fit is one that is acceptable to you and mixes tasks that you like with some tasks that you can at least tolerate. But if you find yourself hating your job, it's time for a change.

One last thing

If you're working long hours or working weekends without adequate breaks, then you could be experiencing burnout, which can make even the most pleasant tasks feel like chores and boring tasks feel unbearable. So part of taking stock of your situation includes making sure that your hatred for your job is really coming from the work and not from burnout-induced stress. If the problem turns out to be burnout, it needs to be addressed differently than if it is simply not liking your job.

Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager.

Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be happy.

I have seen both sides of this. I have re-written lousy code that would take me longer to understand and fix than re-write. And I have seen people re-write code that I thought was OK and maintainable (and break my budget).

After a few times I discovered that I begin "hating" some code base, I started researching why.

And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and...

So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code!

What is most important, you already know them (since they are bothering you) but didn't care to prioritize.

You named a few already: "it's not easy to understand code, especially if there's no documentation." When examining the code, you must have identified that these and these parts are sloppy and error-prone; here and here, there are no tests so no way to know if the code is (still) correct in all cases, etc.

I went through this for a long time. It became something unbearable.

Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling.

I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative.

Now that you have experience, quit your job and look for one that better deserves your devotion. I did it 2 months ago and now I can't understand why I didn't do it before.