Let's Stop Hating Legacy
When I first joined my current company in January of this year, everything was legacy. For the frontend, it was outsourced development, so it was hard to scale further, and the team was trying to replace the legacy product with one created by in-house developers.
The backend was a particular problem, as there were fewer backend developers than frontend developers, and the company needed to launch and scale quickly to grow bigger. So from January to June, the frontend product was being developed without fixing the issues in the backend that were working.
Some queries were too slow, some exceptions weren't handled well enough, and the structure of the responses coming from the backend was too complex for the client to handle, but the web app was brought back in-house, the mobile app was launched, and the chat feature was launched.
I'd be lying if I said I didn't have a few moments along the way where I thought, "Why does the backend look like this, and why am I struggling?"
As we rapidly developed the app, the front-end paid the price for the back-end being legacy. There was so much to do, and it took longer than I thought it would to complete a task, and I often resented the developers or the code that wrote it in the first place.
When you're dealing with legacy that's not going to be fixed anytime soon, or when you're refactoring legacy code, being angry at the legacy, cursing at the legacy, isn't going to make the legacy fix itself. It's more efficient to work in silence and without emotion than to work in anger.
Reflecting on the past six months... I've been thinking about how to think about legacy products.
1.
I try to have some appreciation for legacy first,...because it's been running hard and earning my paycheck for a long time.
I'm a developer, but I'm also an employee of the company, so the company doing well is just as important to my job satisfaction and performance as doing well in development. But if the legacy has been running well and contributing to the company's business goals, then the legacy code deserves an extra pat on the back for all that time.
It's not the company's place to blame legacy for being an unpleasant place to work.
#2. Once the business goals have been established, do what you can as a developer to make them happen
When touching legacy aligns with the company's business goals, developers work with legacy.
As I said before, blaming the legacy doesn't fix it, so I think it's more beneficial to spend time thinking about how to turn the legacy into a good product instead of blaming it. It's better to focus on what you can actually do as a developer.
And the goal of a business is probably not "write clean, nice code to create an elegant product, no matter how long it takes!". Code refactoring or product quality improvements should also be done in line with business goals.
3. Right then, wrong now
When you're building a product based on your company's business goals and timelines, you may find it difficult to keep up with good architecture or all the conventions. Or maybe the business environment is changing so fast that the design choices you made in the past aren't the answer now.
Software is a very unique machine that is always changing. It's also one of those machines where it's relatively easy to improve on past mistakes in the present compared to other machines. I think it's more helpful to the task at hand to have an attitude of respect and understanding for the choices that you or other developers have made in the past that might have been closer to the right answer.
4. My code will become legacy at some point
The code I write will become legacy at some point. Every developer is writing code that will become legacy. I don't think it's necessary to have any particular feelings about legacy, because it's a part of life as a developer.
I think the best thing to do is just work hard and think about what's the best code at the moment, what's the best way to accomplish the business goals faster and more accurately.
And the code that improves legacy today will still be legacy at some point. When we improve legacy code, we don't always have the ability to dramatically improve everything - there may be time or ability constraints.
Software should be improved over a very long period of time, slowly moving towards a better product. Instead of looking at the big picture of change and expecting to improve everything right away, I think it's a better way to keep thinking about what the right answer is today.