I recently read The Software Craftsman, as mentioned in the review, one of the areas that struck a chord with me was the viewpoint on Legacy Code. I deal with a lot of Legacy Code in my day job, I’ll share a few of my own thoughts and experiences on the matter.
Legacy Code – Respect
It’s important to treat Legacy Code with Respect, from all angles. Treat it with respect regardless of how poorly some of the code may have been written, or how antiquated the technology may now be.
We’ve all written code in the past that you wouldn’t dream of writing in the present, this is true of other people too. Before laying into those nested if statements, (or the author), remember we’re all learning, nobody wants a Blame Culture.
Choose Education over Denigration.
Often, Legacy Code will have been written by people who may not be on the project, or even with the company. It’s really easy to bash code like this, but it’s much more difficult to fix the problems and move forward. This is the challenge and what will set you apart from other Developers. Remember, moaning will get you nowhere
Legacy Code – Code as a Crime Scene
I was lucky enough to Attend the DevWeek 2015 conference in London. I attended a talk by Adam Tornhill (@AdamTornhill) titled Treat your code as a crime scene.
While I’ve not had the chance to put any of the analytical tools into practice, it was certainly thought provoking. You can gain a huge amount of insight into the code base and the hot spots, and even where bugs are likely to occur in future by analysing your source control repository.
Legacy Code – Don’t be Scared
It’s important not to be scared of change. The Business will be resistant because their system will likely have been in production for a while, and (at least on the surface) “stable”.
The key point being that you do tackle it, not skirt around the problem. It’ll take time and buy in from the business to do but it’ll be worth it in the long run. Selling the benefits back is an important skill to have in your toolkit. Telling them that you want to upgrade the version of MVC because you want to use Razor syntax is likely not going to work; telling them it’ll allow you to deliver features faster in the future might.
Don’t rush, regular small improvements will make a huge difference in the long term. Pick off areas as you need to change them for genuine business requirements, this becomes a lot more manageable, and isolates the risk in that the code you are changing will need to be put through the test cycle regardless, be that manual or automated.
How have you dealt with Legacy Code? Let me know.