It’s very simple: Because it won’t go away. There, that was easy.
Every line of code you write becomes legacy code, whether you like it or not. Doesn’t matter if you’re using a shiny new framework or something that’s been develop in-house. Sooner or later someone will have to maintain your code, whether it’s adding features or fixing bugs. It doesn’t matter if it’s you or someone else. At some point some human will come back to your code, and will want to do something with it.
So what do you do? You take all precautions so that this person can do his job. You write tests, you refactor and clean up your code, and you make it as readable as possible. Simple as that. You work your way in from the outside.
What happens when you get back to someone else’s legacy code? That depends really. If there are tests you run them, you read them. If there are none, you just write tests. It’s a neat way to discover a piece of code’s functionality. You’ll find some first pointers on where to start refactoring, or where you can add that new feature marketing wants so badly.
Legacy code is something that will give you a chance to learn.
You can learn how to refactor code. It’s not always fun, but I find working with legacy code to be a more rewarding if not always pleasant experience. You get the chance to make code better, to make it easier to read, and finally to add new things. It sounds more glorious than it really is, cleaning up after others isn’t something that’ll win you a Jolt award, but it will deepen your knowledge of the domain, the code, and it will improve your personal skills.
Over time it will get easier to work with other people’s code, no matter how big the mess they’ve made.
Working with legacy code is not a glamorous job. But it’s a skill that’ll give you a lot more knowledge about working with code than constantly working on new projects will ever do.
Mind you, legacy code doesn’t need to be a mess. It’s up to you to prove that.