Legacy code. A topic that doesn't get talked about that much, and doesn't get a lot of love. Last week I gave a talk about working with legacy database structures, and while many nice people came up to me and had similar experiences in their workplace - one stood out.

"I thought I was alone in the world facing these kinds of problems" - he said. He was working as a solo developer in an old application. An application that was created over 15 years ago written in a framework long forgotten and had over the years been maintained by several different people who had all made their "footprint" and rewritten parts of the system in ways they thought was the best.

He felt tied down, and was looking longingly at the all the other people working with new technologies, the latest frameworks and all the new cool stuff.

Here's the kicker. I think most of us are working in varying degrees of legacy code. We aren't working with the latest version of the frameworks, languages or libraries. We are struggling to maintain code bases that have gone through several shifts in architecture, concepts and ideas. People have come and gone, and the knowledge of why things are the way they are has been lost. This is the reality we live in - and thats okay.

The code that we sometimes feel really frustrated about, that's holding us back and that we wish we could just start over with - that code probably have a lot of value. It has built a business, served customers and generated revenue. In fact, that code is paying your salary and the only reason it's still around is because it is valuable.

We go to conferences to meet other people, get inspired and get new ideas. A lot is focused on the new and cool things, because that's what we're excited about. We want to learn about the latest and greatest, I definitely do, even if I probably can't use it for some years to come.

Just don't forget that you're not alone with your legacy, and you shouldn't be ashamed of it. We're all there. Some deeper than others. Some are currently building their future legacy because shortcuts have to be made to meet deadlines or money is running out. That's just the way it goes with software. No app is perfect. No app is complete. We're constantly changing it, sometimes for the better, and sometimes for the worse.

Sometimes it can feel like it's hopeless, a lost cause. But it probably is not. We need to recognise that working with legacy is a certain skill. A skill that needs to be learned and practiced, and that's really hard. Starting a new app can be easy. Maintaining an old app is hard. I've worked with legacy apps my whole career, I still struggle, make poor decisions and sometimes lose faith.

So while talking about new and cool stuff is awesome, let's absolutely continue to do that, but let's also talk about ways of dealing with legacy. Techniques, methods, successes and failures. Let's also share those with each other, and that way we won't feel like we're alone in the world with our problems.

Legacy code isn’t a curse. It’s proof that what we build has lasted.