Why am I always stuck working on legacy software

In my experience, the bitter truth is that businesses rely on unsung heroes who do the crappy jobs with loyalty and duty. They will grind to a halt without these people even though it is seldom recognized or rewarded as such.

As a contractor, I have the option to become that person again and again and again after a year or two with clients. Instead, I say nope, and find other work instead. I have given this same speech to the dutiful employees I encounter many times. Their resistance seems to be rooted in being risk averse and committed to someone/something. But that's all it takes, applying elsewhere, and not accepting what you don't want.

I'm a really big fan of Chad Fowler's reframing of legacy: https://www.youtube.com/watch?v=qH_y45he4-o

TLDW: In most endeavors in life, legacy is a positive thing, a bequest or accomplishment that you leave behind for future generations. Only in software do we have such a negative feelings towards "legacy"

For software to become legacy code, a system has to survive and that means it has to a) work and b) be useful. You're working on something that has stood the test of time. Just as it's much harder to restore an ancient, archeological treasure like The Colosseum, it's harder to work on legacy software... You were chosen for a task that's challenging, but important.

Advice from someone who regularly got thrown on "new tech stacks" and finally has fallen into the "boring" work of a popular language and very defined set of well known standards:

You might think you are "unimportant" and maybe at your company that's true. Looking at it less cynically you could also be reliable, capable of parsing and improving code, and more familiar with a wide variety of code styles. These suit you well to this job and being a janitor often pays really well. Often times as I advanced in the ranks I spent more time modifying other people's code than starting something from scratch.

You don't want to be learning new tech stacks all the time. If that's your personal hobby - great. But these stacks come and go and collecting N number of tech stacks to throw on your resume won't make you any more desirable to a new position down the road that requires senior X or staff Y and you've spent so much time in varying tech stacks you're not at that level. At the end of the day people WANT "boring" engineers. They're reliable, predictable, and knowledgeable.

Two things: One, if you don't like the work assigned to you by a job, it's time to find a new job. There's no other way! As long as you fill that role, you'll be working at the behest of your employer, and although you can try, changing the distribution of work you get is ultimately beyond your control.

Second, working on legacy codebases is one of the most challenging things you can do as a SWE, you're in a maze where the walls are Chesterton's fence. I just left a legacy codebase to write a new app in NodeJS. Granted, it was a lot of work to get up to speed on the ecosystem and carefully decide how to set things up, but the CI is blazingly fast, and the complexity of the same feature in the new codebase might be 10x less, at least for the beginning. For example, in the legacy codebase, adding pagination to a route is a PR that touches 25-30 files. Yes, there are anti-patterns involved, but for the new app, and it's in Haskell, that same functionality can be done in a greenfield project much more effectively.

Of course, everyone wants to work on greenfield projects, make the architectural decisions, and build software without the constraint of past decisions weighing us down, but adding features to and improving legacy systems, IMO, is just as valid of a skill. Good luck navigating this.

The grass _is not greener_ on the other side of the fence, this I can assure you.

My take is, 25 years ago, people were writing software that _had to work_. We weren't writing stuff for "non essential" smartphones and social media networks. Nowadays, most node packages could care less if it crashes 1-15% of the time because they're just displaying kitten and instagram selfies anyway.

I'm in an industry that _needs_ exactness, and a huge swath of frameworks are insufficient; Poor handling of input verification, no edge case detection written, no unit tests, no branch coverage even if tests are written, and worse, just poor code sanitation in general: no formatter, no consistent architecture, no explanation of operating theory, no gpg signatures. These basic practices that were commonplace were something to be proud of and display of your professionalism, something that's been lost.

Call me old. I'm going to go yell at the kids on my lawn now.

From my experience, exciting projects get assigned to people willing to work 50+ hour weeks and be on call nights and weekends if something breaks because these exciting new products are market-share grabs. If you have shown resistance to working long or late hours you will be put on projects that are not as time and availability sensitive.

> My performance reviews go great.

So basically you are really good at what you're doing so you get those assignments. Code maintenance is hard and requires experience and familiarity. Other reasons might be cultural.

In any case, if you want to move on to different types of work then expressing interest is a very weak way of doing it. Even in great teams/orgs you need to do more than just say "it would be nice if".

Make a _decision_ and then inform your peers and managers of that decision. If there is a conflict, then work on resolving that conflict within a reasonable timeline. Compromises can be fine, but you first have to assert where you want to go, basically force people to take you seriously. Do all of that in a professional and rational manner and you'll get there.

It's hard to say without knowing you!

It might be because they see in you very strong skill with old flaky code that others are not trusted to fix but it could be that they see you as old-fashioned, uninterested or unmotivated and therefore they don't "feel" that you will be the right person for new stuff.

You could always build some things and then talk to the bosses and ask them. If they can't give you an answer, it is likely to be a negative reason but if they can say e.g. "we didn't know that you knew this new stuff", you can show them what you have been working on.

In my experience there is a dynamics similar to bullying: employees compete for visibility (height unironically helps here lol) and shipping new projects, while pushing away the rest of us, naturally leading to this distribution of roles.

You have to outbully the bullies (and develop a political presence where people have a bit of fear when they think about pushing their maintenance duty onto you), or at least to become inconvenient for such work.

It's office politics, plain and simple.

Join a smaller company that’s writing greenfield code. There’s still legacy stuff to deal with there, too, but the proportions will be more favorable.

The adage “legacy code is anything committed to trunk” is informative; larger, longer-lived codebases/companies just have more old stuff by their nature.

Have you spoken with management about your concern? Maybe they can help you spread the load amongst the folks doing the AWS migration, allowing you to take on some of that work. If they object you can frame it as cross-training or ensuring redundancy in case of emergency.

If you wait for projects to get handed down to you by your manager then you'll always end up with work that no one else wants to do. If you want better projects, go find them. Or better yet, start them.

Maintaining systems often takes more skill and understanding than building new ones.

That old Oracle database might be old but the business is running on it so it has a lot of importance to the organization. A new project might fall through before it is completed and the people on it would be the first to be laid off because there is nothing for them to do.

I was one of those developers who was always picked to start new projects. I started hundreds of them so far. I don't know why I was picked, but I can give you a list of things that I'd say differentiated me from my colleagues who'd never get the chance:

1. I have high-level knowledge about a lot of tech stuff. I'm that kind of idiot who isn't an expert on anything, but knows enough to be able to pick the right tools and work with them successfully (as in, finish the project).

2. I think I'm really good at communicating with other people in a work scenario.

3. I had a proven track record of finishing legacy tasks on time.

4. I don't usually go around seeking approval from others, especially on the things that I'm really confident about.

5. I'm independent, not only in the code I write but I can also make project decisions, initiate change, handle high pressure situations.

When fixing legacy code, you can become a victim of your own success. The old crusty systems are usually the company money-makers. Once you show some success at fixing and maintaining them, you become the "go to" person for fixing them. That can be a good thing.

It's a tough rut to get out of but I think you have some leverage if you choose to use it. New frameworks and new projects come and go, but that boring hideous legacy system is the one that survives and the one that brings in money to company. Use that to your advantage to get a raise, create some opportunity, or failing that, bounce to a different company.

Greenfield is always more stressful to me. The deadlines are ridiculous and the requirements sketchy.

I suggest two things. You can either do both, or pick one.

1: Go work for a startup, or an otherwise young company. Just remember to screen the company very carefully, because working for a startup is inherently a little more risky than a large, stable, mature company.

2: In your 1-1s with your manager, make it abundantly clear that you're unhappy working on legacy technology and that you'd like to transfer to a team working on a newer stack. At the same time, network within your company to find a team that's working on a newer stack. There may be an internal job board you can look at too. (If your manager blocks you transferring to another team, see #1.)

There's really only two things you can do: ask for it directly and press for a good reason why not, and job hunt where that is what you're looking for (make it clear).

I feel your pain. Legacy systems breed a laziness in me personally. Because I know at best I can make a 1% improvement here and there, so it gets less of my energy. Being new in a legacy thing can help, you come in with green eyes and start fixing things no one else thought to. But that runs out eventually.

You're good at maintaining legacy code. Probably the best way would be to switch jobs, but even then you'll probably find that most code is legacy code.

So, first thing: Legacy code is a profit centre for the company. All NRE costs have been amortized over the years, and the company counts on it to make money every year, money which actually goes to fund those other mostly hare-brained projects. The work you’re doing is often more important to the company than the shiny new port which has a high risk of failure.

The real problem here stems from the promotion cycle that over-rewards new features and under-rewards maintenance work. This is uniquely a software problem as in any other industry, replacing the plumbing is extremely well-rewarded.

Since you are intimately familiar with the flaws in legacy code, you are uniquely positioned to think about what a refactor or a complete rewrite on a different framework, or a different language, or even a new platform, would look like. Whatever you come up with would be a great step forward for the current product.

Once you have a vision, sketch out a strategy and present it to your manager. Then, this is key, regardless of what the manager says, start working on it on the side. Bring that vision into your legacy code either as piecemeal updates or wholesale as a brand new prototype. Once the prototype is working, present it to your manager. Once again, the key bit is that it does not matter what the response is. Keep refining it, because ultimately you know better than they do what legacy code needs. Ultimately legacy code will becom unmaintainable due to deprecation, platform switch or other factors. That’s when your prototype becomes the fastest replacement and gets you the promotions.

In short, you must create your own new work. Don’t wait for permission. Once you are successful at this a few times, the company will give you a much freer hand to implement new features wherever you see the need, since you have proven yourself to know better.

So, they are taking advantage of you by exploiting your loyalty and passing you up for opportunities for growth and responsibility.

Like most of the time in similar situations, you probably have a temper and demeanour that makes it convenient for them to take advantage of you.

Whatever you're doing that makes it convenient for them, you need to change it.

Expressing interest is not enough. Everyone wants to work on the exciting projects. You need to come up with ideas, get involved, and fight to work on the new projects.

You may need to complain more. If you don't like what you're working on, say so.

Have you asked? That would be the first thing I'd do. Make it known you want to do xyz. If a project doing that comes up and you are not chosen for it ask why. Not in a confrontational way but like,

"Hey manager, I expressed an interested in doing xyz over the last three months during our one on ones. project x recently started which focuses on doing y. I wasnt chosen to work on that project. Is there a specific reason why?"

Or go find a new job where they tell you you will be working on xyz.

It's likely just because you are good at working on legacy work and unless you make noise you wont be moved.

Have you had discussions about this with your manager, and made it clear you're interested in working on different things? How did it go? You probably have more agency in this situation than you think.

> Am I a bad engineer or do I come across wrong to management ? My performance reviews go great. What can I do or change ?

You are given legacy projects because you are one of a small group that has experience with those legacy projects. You work on legacy projects getting more experience than anyone else the cycle repeats.

The secret is that while you work on less valuable legacy projects your knowledge is more valuable because of supply and demand. Legacy systems demand people with the knowledge to maintain them, developers chase the latest and greatest tech so there isn't much supply.

Use the experience to your advantage take ownership of the projects and suggest that the legacy code should be replaced with whatever you want and as the person with the most experience you are the ideal candidate to lead the new development.

If this doesn't work ask for more pay or you will walk. Because no one wants to work on legacy stuff you can't be replaced and your boss will know this.

Your boss can pay you more or migrate the legacy system to a tech stack that every one knows so they don't have to pay for expertise. It's a win win for you, you get more pay or to work (realistically lead) the new tech.

New things require initiative, outside the box thinking, ability to test and think around the test for flaws. How to break, fix and document those things in regard to the existing current state of technology at your workplace.

Maintaining established things (no computer related stuff is truly old, only by our "standards"), whether hardware or software related, requires steadiness, and a predictable path. It requires a memory of past fixes and the results and pitfalls of changes made. It requires a knowledge of the complimentary interactions and competing goals of disparate systems on the same system (PC, network, domain, etc...).

There are two different skill sets involved. Perhaps management has evaluated you for one skill set over another. Honestly re-evaluate your ability and self-learn for the desired outcome but note that working with your natural ability is best.

Also note: It is possible you work for a bunch of screwballs that have bad management practices. You should at least consider this possibility but don't make it your primary consideration as it could destroy your career.

No matter what you find, Have Fun!

It's possible that you are more accommodating than others of the company's needs and thus more easily assigned to the legacy maintenance.

If so, the solution is to be less accommodating. Insist on being part of the new development, and that legacy maintenance should be a shared responsibility of the whole team. No one wants to do this stuff, so why should it all be dumped on a few? I think willingness to help with old stuff is good, maybe even necessary -- someone has to do it -- but it isn't reasonable to expect you to be the only one.

You must back this up by preparation to leave. Actually looking for another job may help. Finding a market for your skills may give you more confidence to say "I'd like to stay but I'm not growing in this job and that's career suicide." If, after a number of conversations and some time you aren't getting anywhere -- leave.

If you are a woman, it's possible that you are generally inclined to be more accommodating, and may need to do some thinking (and/or get some coaching) on how to effectively assert yourself.

From Hacker News or Techcrunch, it seems that engineers are creating exciting new software projects everyday, using exciting new technologies.

But in reality, most engineering time in the world is spent doing maintenance work or incremental improvements. This is the nature of building intangible digital products - it's not like tangible products (e.g., building a house), there's not a clear finished line. It's hard to declare a software product as "done". There'll be a lot of ongoing bug fixes, incremental improvements...

In other words, most engineers in the world are doing things that are not hacker news/techcrunch-worthy.

To stay intellectually curious, I think you can try to build side projects while learning new technologies. But I think it's also okay to treat your day job like ... a day job, just like other professions. No need to feel guilty for not using new tech or doing exciting things. You are bring in paychecks to support your family, and this is a great accomplishment already.

The pessimist in me thinks that maybe there is some other factor that you're negatively being pushed to do what others might think of as boring. (I'm referring here to race, gender, etc. But i won't dive into those, as others have better advice.) Now, as a counter to my previous statement aboiut you being nudged into a less desirable role, well, you can always work to embrace the "maintainer" role, and work to command more in salary, etc. If management won't/can't pay more, then use "participation in newer projects" as a "reward" in place of compensation. This opens up a whole separate, bigger topic of overall compensation...but maybe you can use some of the good that already bring to the org. as a negotiation tactic to get what you want.

Now, the optimist in me says, hey, don't worry, being good at the "maintainer" role, especially for legacy code is a highly desirable, excuse me, highly *hirable* experience to have. Do you know how much legacy code exists out in the world!?! This makes for tons of opportunities to make plenty of money as a consultant/contractor. Remember during the pandemic, i think it was the state of NJ was begging for COBOL programmers, and you think they would pay crap since they were in such dire straits? Ok, maybe COBOL is a stretch example, but believe me that you can make a very healthy and profitable living as being a maintainer of legacy code. I suggest you research what tech stack is most commonly needed out there by reviewing job descriptions.

Of course, if you really, really want to only work on the newest things...then startups are your likeliest destination, or maybe just do it on the side yourself. Nowadays, myself, i want to work on legacy stuff...because i would rather get highly paid for somewhat boring stuff to manage (extra great if its boring AND EASY)...and then on my own time, i can have my own side projects, or maybe volunteer (code-wise) for one of my local non-profits, etc. Good luck!

Are you more junior or senior than the team working on greenfield projects? Management often keeps people in maintenance either because they've stereotyped them as too green or too seasoned or maybe just they have pigeonholed you as a backfield/anchor player. Another component is assertiveness. Sometimes you have to make friends with someone on the other project & inject yourself into it. You know, "it's easier to ask forgiveness than permission." The easiest way would be if something from the greenfield project interfaces with or shares functionality with legacy systems you've worked with. If the manager hears from another team member, "Ned is helping us interface with legacy Foo & knows a lot about Bar" then they'll see you bring cross-fertilization skills.

There is a huge amount of "legacy" software out there and a huge amount of software dev work involves maintaining it.

This is as it should be. It means that the software which people have already created is working and generating value. It's not necessary or desirable that as an industry, we should keep making new things non-stop.

Maybe you really want to be one of the people doing "greenfield" work. If that is really important to you, start looking around and see what other work opportunities are available. Your current employer might give you that opportunity if you ask, but they might not. If they don't, does it matter enough to you that you would switch jobs for it?

Don't worry about whether you are a "bad engineer" or not. That's just a distraction from the actual issue.

The people you perceive as getting “picked” for good projects are in reality probably generating those opportunities for themselves.

You can do it. Ask around and figure out what the important problems are for your organization, who is thinking about those problems. Talk to them. Design concrete solutions. Go ahead and start moving it forward.

No one is going to walk up and say, “Hey quit doing things we didn’t ask for!” Or if they do, ignore them. They’re not going to fire you when you’re working hard. Eventually someone will say, “Look how much initiative and leadership this person is displaying! Thank God somebody is doing their job around here!”

Not sure what precise industry you’re in, but general advice is to not bother with certifications. Just start solving problems and learn as you go.

Somebody has to mantain "legacy software", heck you can even tell that all software becomes "legacy" at some point.

Without knowing you it's difficult to know why are you selected to work on legacy software. Maybe you're great dealing with old code bases? Maybe other people has a better marketing and come as "rock star" engineers that can work with the last technology?

There are two possible "solutions" I can think of:

  - Move jobs once you're assigned to work on legacy software (change jobs each 2-4 years).
  - Work in a startup where all software is crucial for the company and even if there are no good-practices, you'll learn many "shiny" technologies.

Hey take it as a compliment, would you throw a Junior developer into a complex and already working legacy system? try to answer it from the business point of view; it takes a lot of experience and knowledge to do what you are already doing.

My recommendation is to apply the 80/20 rule, use around 20% of the time to do fun stuff like refactoring that annoying class or package, add tools to react quickly to errors or to understand sql queries like tracing and better logging, take the time to write test benchmarks specially for slow functionalities and add faster or more readable code, it's fun I promise it, this's exactly what I'm doing now :)

It sounds like you’re good at working on those legacy systems and become more so as you keep working on them. As long as the legacy projects are there and need a maintainer, of course you’re going to be offered that opportunity.

So then what happens? You get offered that role. What do you say?

That’s the part you might need to work on. You might be giving an answer that is in more service to (say) your sense of duty than to your career ambitions and creative interests. Give some thought as to which is really your priority.

The grass is not always greener. In my experience, this is especially true of 'migration' projects. Migrating an existing system to a new stack can be the worst of both worlds if the existing system is complex and poorly designed. I am living through this right now migrating a 20 year old tangled mess of a system to 'the cloud' and it is a nightmare.

There is a lot of good advice from others here on how to pursue things though.

I got the exciting job migrating Oracle Forms to Oracle Jet and learning new JavaScript stuff. Job now: Spend half my life having to rewrite everything since the Oracle Jet team constantly deprecate features, replacing them with some new "Looks the same but completely new API" feature that I then don't have time to learn

I would just be happy that you have a job you're good at. I switched teams multiple times. I'm tired of it. I wish I could do the same stuff and actually build expertise. I'm too old to continue on this treadmill. I recently switched teams and I'm concerned about just being able to keep my job.

> unimportant legacy projects

are they really unimportant? My goto question to find out how important something is: what happens if we turn it off?

Usually the answer is "haha please do not".

Ask the same question about "new projects that involve new tech stacks". Then proceed to the next step of the OODA loop.

Well you're looking after the stuff which is working and making the company money, the other engineers are working on stuff which might make money, or could be a total trainwreck.

The grass is always greener, maybe you could get a side-project on the go if you want to work with new tech?

I mean Oracle man, people don't use enterprise software if they're into the cutting edge. they're into cya and vesting. your stay-here option is to apply a new stack to a business problem, make that case to your boss as something to work on, and see if they say yes.

By your description of the situation, it sounds like your job considers you reliable and valuable.

They have you working on the thing that runs their business. They might be picking other people because your job can afford to let them go off and try something that may fail.

Something to consider, anyway.

If you don't want to do something, don't learn how (or don't admit to knowing).

Candidly though, any project with the word "migration" in the name is not one I'd be salivating at. Those are all long slogs of tedious fiddling, in my experience.

Software maintenance is the most important aspect of software development. It's great to work on new stuff but at some point it has to interface to legacy code so know that code becomes a requirement.

Did you consider the majority of work in large companies is legacy and maintenance.

As a senior your best chances to work on new projects a early stage startups.

Everyone literally has to work on something new.

in my last company, the under performing engineers were moved to work with legacy stuff. greenfield projects were given to senior engineers.

i think management put higher priority in the new project and needed more experienced engineers to get that going as fast as possible

Start by asking for new projects?

Maybe you are better than your coworkers at maintaining code.

So that you can avoid doing the bulk of the tedious crud.

You can begin to say no.

cause it makes money