Sunday, October 30, 2011

The gift of legacy

Just after graduating, I hated legacy with the heat of a thousand suns. I felt unfortunate, having to work on old code, built using outdated technologies, while software is all about making new and shiny things. Right, guys? Those naïve expectations of a rookie got crumbled very soon. Legacy is a constant in our industry. You can try to ignore it as long as possible, but it's impossible to keep that up forever.
Over the years, I have come to accept that. I even have been fully embracing it lately.

Legacy is an opportunity to learn from the past. To learn from the costly mistakes our predecessors made, so you can avoid them in the present. Often legacy also helps me fully comprehend the motivation behind more modern architectures and software practices. Finding yourself all alone in thousands of lines of code, where the smallest change can impact an unknown amount of long forgotten scenarios, makes it perfectly clear why we test our code, and why it should be a crime not to.

It's a shame that there often isn't a whole lot of glory in maintaining old software. Although, I do think some programmers should be awarded a medal of honor after serving multiple months in the trenches. There is, however, a lot of space to make small refactorings, improving the code quality and in the meanwhile giving you the small wins you need to keep going.

All legacy isn't bad per se though. Once in a while you discover a ruby in the dust; a creative solution or a small but interesting trick, which you might be able to apply later on.

Legacy is a gift, learn to embrace it.


  1. When you write your own product, which your customers trust and will benefit from for many years, the code behind the product will eventually always become legacy.

    On the other hand, although it requires a greater investment during development, writing code with as little dependencies on the current technologies as possible, keeps your code portable to new platforms in the future.

    It may then not be as shiny as the current technology, but it doesn't make the "legacy" part a burden, but a strenght. It should be considirated at the start of each project.

  2. Of course not all the legacy code you'll face is automatically bad. As you stated in your blog, sometimes it can be well-written and makes your programmers life a bit easier in the future.
    However, if not... be methodical and take some things in consideration. Why was it coded that way? If available, read existing comment lines or blocks. This will help you interpret the line of thought behind it. Make sure you create a good set of tests whenever mixing legacy code with your own because any new bug can have a cascading effect on the rest. Always consider rewriting parts of legacy code because sometimes it's quicker to rewrite from scratch than modifying or knitting your legacy code.
    Have fun @ DePost! :-)