Adventures in Legacy Code with New Code
Published: May 15th 2016
Wowzers, okay so it's been a very crazy year so far. Coming out of a year of renovation work at home and crazy hours at work, little was achieved on the tech-front outside of what was necessary for work. This year saw a re-doubling of efforts to not get into the same situation.
This year saw my business, Tohu Muna take on a contract straight away in the New Year with a wonderful family-and-friend run wedding venue in Gretna, Scotland. I put together a development plan for a new website with a mobile-first mentality and called in a designer friend to sketch out some ideas for the website. Over the subsequent weeks we carved away at the rough idea as client and service provider and launched a brand new site for The Chapel, Gretna Green.
I'm pleased with the results, but more to the point, the client is pleased with the result. It took some time to whittle down to what was needed but it kickstarted the year with something to get my teeth back into planning and developing for myself which was a welcome break.
Subsequent to the Chapel contract, a long-term contract came in to develop additions and modifications to a legacy codebase for a local company. This one was a difficult start due to the very customised hand-rolled framework used for their main systems. It's been a while since I've taken on a legacy project as abstractly intricate as this and I admit to being more than a little overwhelmed at first when items that would take minutes or hours to achieve were taking hours and days.
It's been good to have a look through the codebase and see how iterative cycles of development have extended things, in places it does feel very "18th century manor house with Victorian conservatory and 1970's garage" with things that don't quite seem to sit together.
Legacy project handling
The process of work this year has yet again put me into the place I seem to perpetually return to - that of taking on legacy codebases and having to reverse engineer what's happening. I think every programmer, system administrator and database engineer ends up this way after being in the industry for a canny while. You start to see patterns in the way software and services have been put togther, the demands on the developers at the time for quick-fix changes , or the emergency patching over the top of a product to make it do something it was never intended to do.
I'm as guilty in this process as anyone else and the recent work on greenfield versus brownfield development has given me a renewed sense of responsibility for future development work. A key issue I always seem to find is a lack of documentation and comments in the code. I understand that development timescales can be very tight and there's a tradeoff with developing versus documenting for many people - but it's like building your own death trap without an escape plan.
I've been doing some digging around at code analysers and re-investigating my own current codebases to see if I can further optimise and document ahead of upcoming development work. With luck, I won't be returning to my own systems with a mouthful of bile.
Next Item... Cisco Meraki WAP
The Long Dark Quiet