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?
Oldest comments (27)
either avoid or convince them to rewrite with something modern and maintainable. life's too short to wreck my brain with someone else's choices they made 10yrs ago 😋
I was in this situation not long ago, with a homemade framework with no documentation, a lot of variable abreviatated names (like $v, $d, $c) and method, no autoload (lot of require) and other old stuff.
What i did was just to dive into it. Even if i didn't like it and i was often irked at how the framework was made. It get better the longer you are in it, you also learn a lot about the language in general (php in my case), and you should and should NOT code.
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.
My approach is to just make necessary changes and prays it does not break anything (literally). There's even a bunch of files with 6k line of code and everybody relies on that and since the old devs have resigned, we're just basically coding while hoping for the best. Right now we're in the midst of migrating all the important features so hopefully we can finally shutdown the legacy system.
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.
When I started working with a huge legacy codebase, it was very normal to spend an entire day just reading the code and trying to understand the flow. A year later, I’ve gotten a lot better at it, but sometimes I still find myself dreading to make big changes to the pile of spaghetti code that might break something or everything.
"an entire day" ‽
I've spent weeks inventorying code (while also working on new features, granted)
Top-down coding lost its cachet in the '80s, but it's the best way to avoid creating "legacy code": instead of a big mess of spaghetti, at worst one makes lots of little bowls of macaroni, which one can refactor individually
At first time, it looks awful for me.
After above times, I try to improve them about reliability, flexibility and scalability.
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 👌👍
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
🤣
Hahah, this made my day 😂😂
It's so easy to do it these days. I dockering them so that they survive as long as they could. For example, I used to create an application for my uncle's clinic. It was 13 years ago, I was 27 at that time. The application has still been using until now. Over time, technology outdated so quickly. I was using LXD to contain them in a legacy environment. Then, the second attempt was using Docker.
Tada! Meet my very nostalgia creation...
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.
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!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.