Legacy Code: A tale of horror
Part 1/2: What is it? Where did it come from and how to stop it from happening.
There is an ancient evil haunting all workplaces. It’s known as legacy code.
It’s the stuff of nightmares. The kind of thing that sucks the life out of any developer and kills careers. A frankenstein’s monster of spaghetti code, bad practices and zero documentation, forged in the fires of Mount Doom and FTP’ed into the domain of mankind.
Behold! The main.css file; Thousands upon thousands of lines, selectors a deadly mix of id’s, class names and some base selectors thrown in for good measure. Careful! Touch this and you will send ripples through the entire codebase, breaking more things than you fix.
Look out! Here comes scripts.js. This foul beast may or may not be minified with no trace of the source. Loaded up with globals, deadly setTimeout’s and a few versions of jQuery.
We haven’t even gotten to the server side yet! This is where the real evil resides. Legends tell of a developer trying to trace down a memory leak. Deep within the core you can still find his comments. “I think I’ve found the source”… “Send help! I‘m stuck in an infinite loop”
All these files usually suffer from severe schizophrenia. Created by a series of developers and so containing every coding style know to man. Spaces, tabs, cowboy coding patched together with quick fixes and broken promises.
How did it end up like this?
Who’s to blame? How did this abomination come about?
Unfortunately, most of the time these types of projects probably came into being several years ago, at a time of turmoil. The web was a chaotic place until very recently. Browsers beasts in their own right. Standards not quite… standardised.
A product of their time, of budget constraints and deadlines. Of new developers still finding their feet with no time to read about best practices. (Definitely no time to write documentation or tests)
It’s not hard to imagine a new team starting out and you finally winning some work. The hard lessons not yet learned, diving head first into a web which, let’s be honest, only recently came out of puberty. We only just realised the C in CSS sucks!
Then throw in the usual spanners. Client changes. Post-launch feature requests. Quick Patches. Urgent Fixes. “Oh, can you just move that there?” “We need another language added!” “Can you make it pop more?”
What chance did they stand?
If they had know the pain and technical debt they were passing on, would they have started over? If they had seen into the future and come to realise that in 6 years more hours would have been spent debugging their code than the total hours it took them to build the piece of shit?
I doubt it. There were bills that needed paying.
So.. You’re saying it’s ok?
No. I’m trying to illustrate that toxic legacy code isn’t caused by some lone gunman but by a series of failing processes.
The only way to combat this happening is to learn from the past and prevent it from ever happening again. Create a culture of doing things properly. Get everyone on-board, not just the developers!
Maiz Lulkin puts it much better than i could in his excellent article “technical debt 101”:
In software development, the dreadful consequences of sacrificing quality are widely misunderstood by non technical managers. They underestimate how detrimental it is to continued productivity and morale, and ultimately, to the overall strategy of the company.
There is no excuse for writing bad code today!
Browsers are much nicer. There are tools for writing documentation and tests that should take no extra time. There’s countless of amazing free resources out there on best practices. CSS shouldn’t be global any more. We have task runners that do most things for us, so there are no excuses!
Write tests. Write documentation. Make sure the entire dev team follows the same conventions, so spend time on training. Talk to each other! Don’t take shortcuts or put things off. You’ll never magically find time to come back to it. If you don’t tackle those issues now then you might just be creating another monster.
The time investment of doing things properly will always pay off tenfold down the line, in both time and not having to constantly look for new talent because your staff are literally burning out.
Conclusion
Legacy code is one of the worst things about my profession. It could and should be a thing of the past.
So what can we do about the existing mess? A complete rewrite is not realistic in most cases.
In part 2 of this post, my friend Dave will discuss specific approaches.
My take on this is (even if it seems impossible), start implementing best practices with each fix you have to add. Try to break it up into pieces you can more easily manage. This won’t be easy, and it will take longer than just slapping another hack to the bottom of the file, but at least now part of the evil is exorcised.
Plus, you don’t have to feel dirty when you finish..
