Most of the devs are aspired to learn cutting-edge technologies and develop new, innovative products cause it's fun and adds a lot of value, keeping them excited and inspired.
In reality, tho, the vast majority of the open roles are often seeking devs to maintain their monster-size code-bases often written in outdated frameworks to fix bugs while avoiding damage to major dependencies.
How do you keep motivating yourself to deal with continuous legacy projects? Or do you try to avoid them at all costs?
Top comments (27)
My approach is usually divided into two: first I start to decipher the code like an archeologist, with a lot of WTFs and WHYs. Then, when I realize that the project is a total mess, I cry a lot until I end up with a fix that doesn't break all codebase.
I love legacy codebases.
First riddle is how did a bunch of smart developers create a codebase like that? Are you doing anything so significantly different that you aren't leaving a legacy yourself?
Ok, now that I've ruined everyone's day lets get into it.
Legacy code is an odd animal because it generally does the job it was asked to do, but is generally hard to understand and harder to change. So, first thing I like to do is respect that this code is doing its job and someone is getting something out of it.
Most legacy codebases suffer from a problem that nobody can keep it in their head or remember what it does or how a feature behaves. Most legacy codebses don't have tests either.
You're writing tests right?
So, all you can do is accept that the code exists the way it needs to even if it looks broken or buggy. Now you need to protect that code from abberant change by writing some tests. These tests don't tell you it works, but they do tell you if its behavior changes. You need that.
With some tests you can now begin to make changes where you surgically adjust functionality while cleaning up as you go. The tests inform you that behavior is maintained as you work.
Last bit is the temptation to rewrite or start a new project. Rewrites are a disaster waiting to happen. Remember that depressing thing I said earlier? Compound that with the fact that nobody knows what this thing does and you have a recipe for a instant legacy codebase that fails to do what the other one does too.
You can implement several isolation patterns in place like the branch by abstraction or strangler to slowly but surely create a modern implementation of it. But before anyone tries this, they had better be serious about working in a significantly different way or they'll make it worse.
"Most legacy codebases suffer from a problem that nobody can keep it in their head or remember what it does or how a feature behaves." 👉 That is so true 😅
Highly recommend reading Martin Fowler's book Refactoring. One of his main points is that refactoring code should continuously be part of the process of software development, especially when handling legacy code. He provides some great examples of refactoring, provides lots of refactoring techniques, and even addresses why its so important and how to advocate for time to do it from management. I just read this book and have found it invaluable for refactoring some code I wrote 5 years ago for a personal project. Check it out!
I picked up a project two years ago as a freelancer. An iOS and Android native app. Documentation was non existent, previous devs could not be contacted. Problem was: We needed to immediately start releasing updates. My best friend during this time was the debugger.
In the end I convinced my client to rebuild the entire app in react-native and maintain the old code until the new app was ready.
I do not generally avoid legacy applications, but I think it is important to be honest with your customer. If the code and documentation is really bad and beyond repair/maintenance, I try to convince him of the benefits of starting (at least in part) from scratch.
In my experience, trying to patch around broken projects will never make your customer happy, frustrate you as a developer and ultimately be more expensive in the long run.
This is well put 👌👍
The stallion coder doesn't deal with legacy code. I rewrite all of them every year.
Dependants? It's your problem. I gave you 30-day notice on deprecations, and then it's removed. You are supposed to rewrite dependant code every year, too.
Look at those lines and lines of code inside for loops and no try catch till I reach a point where I use a punching bag to relieve all the anger and then start to think about ways like caching, splitting into services, using linq and then when you present all the finding and improvement you manager replies saying we would not get the approvals or its to risky. This is happening in one of the big 4s and killing urself is the only way out
Basically there are three options: refactor / rewrite / replace. In my experience you must consider refactor first, even if you want to replace whole code. If you rewrite or even replace whole code base, you must face similar issues which solved by the legacy code.
It seems like you are asking two different questions:
Let me know if I have misunderstood, but I will answer the two questions that I read from your post.
1. How do you approach work involving legacy projects?
You wrote:
So it sounds like you're working with poorly documented, not tested, possibly in-house made frameworks that have bugs or need additional features built. And you are thrown at the task, and expected to do the work.
I would start with a few questions:
If the required work is more than a small bug, and the timeline is unreasonable, I definitely express that thought and push back for a more reasonable timeline, especially if it's my first time with the legacy codebase. If the timeline is immovable, and the work is fixed in scope, then I make sure to mention that this should be an exception, and that I will actively avoid or refuse that sort of work next time. (We are fortunate to be in a career that is in high demand right now, so I think we have leverage.)
Now that we know the timeline and work required, I would go through the concurrent acts of a) finding where the work needs to be done, and b) documenting and adding tests for as many places as I can on the path to the work to be done.
This allows me to solve the problem at hand, but also make the codebase easier to pick up next time someone else (or myself again) needs to do work. Even if it's as simple as "running this locally" instructions, it's better than nothing!
2. How do you deal with having to work with legacy projects?
You wrote:
The real meat and potatoes of your post, in my view, is how does one continue to develop their career positively while having to work with legacy projects. It's a great question everyone should ask themselves, if they are ever posed with the situation.
Having been there personally, there's a few thoughts I had while my team took on more and more legacy services, and having to maintain them while building out new features:
In the event that the above opportunities do not exist for the work you are doing on the legacy codebase, then I would communicate that your career growth is being negatively affected by the work, and ask for either additional work, or to be moved somewhere else entirely.
If that's not possible, it could be time to start looking for new opportunities.
Microservices is usually the path forward. Monolithic code bases are insane. Nobody can do anything in there and splitting code makes everyone life easier.
It does involve software architecture to understand what is going on and having a path of switching traffic from one path to another. A/B testing would be ideal.
Hope this helps.
Simple - stop writing legacy code. Too many projects are 'on the road to legacy' from the day they were born - write good tests and enough documentation and comments (comments the WHY of code) so that the next person at least has a vague idea what you were thinking at the time. Practice TDD 'test-first' so that your tests describe your system's intended behaviour at an appropriate level of abstraction (i.e. not all unit tests, that just demonstrate that a component meets it's public interface)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.