Working with legacy code can be challenging and frustrating, as it often requires extensive maintenance and debugging, but it may also have a stable user base, which can provide job security and professional growth opportunities. Starting a new project with a brand-new tech stack can be exciting, but also comes with challenges like steep learning curves, it can be risky, and it may take a while to get the project off the ground and gain traction.
Which would you choose and why?Or which have you chosen? And how’s it going?
Follow the CodeNewbie Org and #codenewbie for more awesome discussions and online camaraderie!
Top comments (10)
It seems like most people prefer building something brand new, free from other people's choices. You can learn a lot about architecture and design that way, but you have to stick around for a while to see the long term consequences of those decisions. Plus, you can get stuck in your or your team's way of doing things.
All my professional experience has been working in legacy/brownfield projects, and the lessons learned have been invaluable. I wrote 8 Things I learned Working in a Legacy Codebase a while back. Now, I'd say the benefits are
Thank you for this perspective!
Well, I had the opportunity to start on a green field. And I did enjoy it, but I've stuck around long enough for this thing to become legacy. And I enjoy maintaining and enhancing the structures I built on it. I'd say, the real question is: are you willing to live with your decisions over a prolonged period of time? Anybody can jump ship every 18 month or so and leave the mess to somebody else to clean up (this also works without changing the company). In a complex environment, excluding ramp up, that's hardly enough to make a dent in the system.
My specialty is creating new legacy code
😂
For technologies I have a firm grasp on, I'd always go for new tech stack. It's more fun, challenging and fulfilling altogether.
Wheras legacy codebases provide the essence of years of development. They give insights of how developers implemented features on an existing product. On the downside, if not documented or written as spagetti code, can really mess with your head.
Legacy, because you always have what to improve 😀
How about both. As a Rails dev, I absolutely love the direction that the platform is moving. Love coding Turbo/Hotwire reactivity into a UI. However, for the last six months, I have been working on a contract upgrading legacy Rails application. I have upgraded two Rails 4 apps to Rails 7 and replaced legacy software with Stimulus/Hotwire. Do I love the new technology and it is my choice for personal projects, but I am appreciating the legacy technology and acquiring an appreciation for the future direction.
If I have to own the codebase and maintain it going forward, I prefer being free from as many historical decisions as possible to implement a solution my way.
But if I'm just there to deliver a specific outcome without needing to worry about maintaining things long term, send me that legacy codebase, I have an hourly rate that makes those efforts worthwhile.
IMO, working on a legacy codebase(spagetti code) is challenging and is similar to playing Jenga because any change you make may cause the tower to collapse, and you may not know what you don't know. Personally, I prefer working on a new tech stack because it offers more support and resources such as documentation and tutorials, scalability, access to more modern tools and technologies, and many other benefits.