digital business | Nov 29, 2018
Time to change your attitude towards legacy code
Got a ticket to a project nobody has touched in 3 years? Here is how to deal with it.
A burden from the past
The code we write tends to have an expiration date. This is especially true for systems under continuous improvement, like websites and apps, where a fresh start with the codebase is a rare luxury.
Developers working on these systems will come and go over time, each building on top of their predecessors’ work. Inefficiencies, temporary fixes and other symptoms of deadline pressure will slowly build up like bugs on a windshield, making the road ahead hard to see and eventually causing accidents if left uncleaned.
Usually this kind of potentially expired, a hard-to-maintain code is referred to as legacy, and I’ve yet to meet a developer who honest-to-god likes working on it. It consists of building new features into codebases written by complete strangers years ago, and not knowing if a functionality is abandoned or a critical piece of current program flow.
Start afresh? Most probably not
Like it’s often done in software engineering, I’ll use house construction as an analogy for this struggle. Ideally, building software is like working on a brand new lot: you get to choose the room layout, floor materials and at what time the sun shines on the kitchen table. Everything is up to city code and done by the book. The finished building is an image of your team’s vision, and you can be proud of every part of it.
Repairing the pipes of a 1950s apartment building, however, is a trickier operation. Even expecting the worst, the level of stupidity of some of the decisions made by the original developer and subsequent renovators will be through the roof (pun intended), and you won’t know if tearing down another wall will cause the whole building to collapse. At this point, you have three options:
- Call in the demo squad and start afresh. This is the most expensive option of the three, but it completely removes the problem of legacy. This is the favorite option of all software developers, but usually not really considered due to orders of magnitude higher costs and development times.
- Cross your fingers and hope for the best. Tearing down a wall to get access to piping is not going to cause the whole building to collapse, right? In day-to-day software development, where the stakes aren’t as high as in building construction, this is often the unfortunate choice: avoiding to fix incompatibilities in existing code caused by the new changes. It saves time and money but just adds to the incomprehensibility of the codebase.
- Take time to understand the project. Find out which walls are supporting, and make reinforcements around them before getting to the pipes you’re interested in. This causes extra work unrelated to your actual task, but if you’re smart from the get-go, you allocate some time and money for surprises like this. You improve the overall system instead of causing further complexity.
How to cope with legacy pain?
Lamia, going strong into its seventh year, is a young company, but we too have had our share of legacy pain. Old Magento 1 -projects made elsewhere without using Lamia standards have been especially agonizing to developers since test coverage is usually 0%, the previous developer’s dog ate all the documentation, and some of the code patterns are questionable, to say the least. Direct database connections littered in template files, MyLittlePony nomenclature for variable naming and dozens of “// TODO fix this asap” comments. We ourselves haven’t avoided the naughty list either, having untested code and now-replaced developer tools, build scripts and npm packages in projects from our early days.
On a personal level, legacy can be a good thing. Reading your own code from last year and thinking “What is this crap?” means you’ve improved yourself. Legacy is a beautiful benchmark of developer progress. It’s just that often you have to go back to those old projects and change the program flow a bit or fix some bugs. It doesn’t feel good to receive that support ticket, but just like we learned to like Brussels sprouts as children, there’s nothing preventing us from having to work on legacy systems and like it.
A change in attitude is required. Treat work on legacy code as a first-class developer activity. Make it a priority to leave an old project in better shape than you found it in. This includes writing unit tests for the functionalities you modify, documenting details you discover while trying to understand the program flow, and bringing project infrastructure such as developer tools, build scripts and version control up-to-date when possible. Soon you’ll be looking forward to the next time you get a ticket to that project built in summer 2009 by another company now out of business – trust me on this one!
Want to find your love towards legacy?
We are always looking for brilliant developers excited to build new great things with us! We also appreciate patience and understanding for code that’s seemingly written by the customer’s teenage nephew, because those kinds of projects will always surface, ready for a brave soul to take them on. Check out our open positions here.