It's a Very Scary This Dot Halloween: LEGACY CODE

WHAT IS LEGACY CODE?

This is a very fitting question for the Halloween season, because if you ask anyone on your business’ web development team, their immediate response might be to run out of the room, screaming, as if being chased by a masked killer. Like Freddy Krueger from A Nightmare on Elm Street, it’s a remnant of a company’s past that comes back to haunt the dreams of present day developers. It’s the Necronomicon Ex-Mortis from Evil Dead- the ancient text, written by nameless, faceless beings, that releases terror when opened.

Alright, that might be an over-exaggeration. But trust me, the topic of legacy code has long been memeified in the web development community because of how challenging it can be to work with. That being said, it really is less Leatherface from The Texas Chainsaw Massacre than it is Sloth from The Goonies. Sure, it’s a little scary at first glance, but ultimately legacy code is highly misunderstood, and can be an amazing asset to your team.

Legacy Code has a number of definitions, but it’s generally safest to describe it as code that was primarily authored by developers who are no longer working within the company or project, and which often utilizes superseded technologies, custom built elements, and parts that are either totally or partially inactive. Sometimes it’s difficult to convey how a codebase grows and can deteriorate over time, and how that can create future problems for developers, but for the sake of this spooky themed blog post, let’s use the analogy of the Frankenstein Monster.

IT’S ALIVE

If you’re familiar with the old James Whale Frankenstein movie from the 30’s, you would remember how excited our friend, Henry, was when he finally got his monster to open its eyes!

Now let’s imagine that, after a long day of his monster running amok, Dr. Frankenstein notices that his creation is limping a bit. Upon closer inspection, he notices some wear on the monster’s ACL. Knowing that he needs to get him up and running as soon as possible, Henry chooses to patch up the ligament with a fast fix rather than the best conceived repair. He could take some time in his lab to test out a better anatomy, or really open the monster up to ensure that perhaps another problem isn’t contributing to the monster’s limp, but he doesn’t have the time to do that. There are villagers to terrify!

A few years of monster maintenance go by, and a lot of these workable, but maybe not optimal fixes have piled up, or have been discarded, or have been replaced. When Henry finally passes the project on to Fritz, his assistant, Fritz will have a tough time making sense of all of the monster’s features, and how to best begin working with it when he has no basis for making sense of how all of the repairs, optimizations, additions, etc have impacted the Monster’s function.

Similarly, it’s very tough for developers to make sense of a highly intricate codebase that they have never worked on. It’s not always easy for non-technical professionals to understand how code can decay, just like a house, car, or a creature made of the piecemeal limbs of excavated bodies. But challenges such as scale, feature demands, and technical limitations often force developers to create highly convoluted codebases that work for them as their architects, but are hard to make sense of from the more objective perspective of a fresh set of eyes.

For the next part of this analogy, we’ll fast forward to what I think we can all agree was an especially… interesting… time for cinema: the mid 2000’s.

IF ANYONE FINDS THIS, IT MEANS MY CODE DIDN’T WORK AND I’M ALREADY DEAD

I apologize in advance if you haven’t seen this movie, but fortunately, what I then thought was an earth-shattering, deep look into the far reaching consequences of our choices, was really just an opportunity to capitalize on That 70’s Show, and give the people of 2004 what they really wanted: shirtless Ashton Kutcher.

Yeah, it’s not that complicated, you’ll be fine.

In the “psychological thriller” The Butterfly Effect, Kutcher’s character finds that even the smallest decisions can have devastating impacts on himself, and his friends.

This is honestly a great analogy for what is often known in coding as “The Jenga Effect”, which is a particularly pressing anxiety for people working with legacy code. In many legacy codebases, different elements of the functionality might depend on code referenced in other parts of the base- sometimes these connections can be so confused and convoluted, that developers refer to it as “spaghetti code”. For these new developers, there is a constant fear that making even a tiny change to the functionality of one element of the codebase might lead to the complete obsoletion of countless other features, with no clear recourse to fix the problem. And unfortunately, closing your eyes and willing 2000’s era Ashton Kutcher to save you from making those keystrokes probably won’t work for you (trust me, I’ve already tried).

YOU WILL DEPLOY IN SEVEN DAYS

Legacy code is like Samara, the little girl who kills you if you watch that creepy VHS tape in The Ring- the better you understand it, the less likely it is to hurt you.

In fact, legacy code, when approached with the correct mindset, can be an awesome tool to improve your company’s codebase, set precedents for your development team’s culture, and better understand the challenges that past developers encountered when working with your technologies. Whether you choose to work within the old codebase, or use it as a roadmap for creating a full migrated system, legacy code is a gift. It is an asset that reflects the talent, knowledge, and beliefs of teammates who contributed to the past success of your company. It has proven its worth. It's been in production, has been used by real users, often times for up to years, and has been patched and fixed after countless bug reports and user research sessions.

As digital technology advances, the worst thing that we can do as tech professionals, is to mock, chastise, or discredit the work of past teammates, or superceded technologies. The tech labor pipeline has exploded with new developers who may have never seen the technologies that they started with fall out of relevance, but with the speed at which digital technologies are transforming, and new areas of web development are being explored, it’s pretty safe to say that everyone’s code will someday look foreign and overly convoluted to the next generation of fresh developers.

What teams should do is take time to examine the code- audit and document its features, run tests, figure out what elements are actively contributing to the functionality, and why. Developers should consider why remnants of past functionality might still exist- is there a possibility that the developers were exploring features that reflected past company goals/values? Are there systems in place to mitigate unique challenges to the successful function of the codebase? Maybe there are deeply embedded processes, unique to the real world functionality of certain applications, that can be identified and simplified through teamwork.

I SEE DEAD FEATURES

One of the most difficult, but most rewarding challenges or approaching legacy code, is sustaining dialogue between the development team, and non-tech management, to determine what features are important to the future function of the codebase, and what aren’t essential. Whether you are updating the legacy code without migrating, or you are completely rewriting the codebase, legacy code can be a foundation on which a conversation about what features management wants to keep, and what features they are interested in parting with, can be built. Having this dialogue will not only improve communication between the C-suite and the development team, but will also instill a sense of direction and mutual understanding about how your company’s technical progress relates to its goals, and values.

This is obviously easier said than done. Approaching legacy code with not only technical expertise, but purpose-driven strategy requires significant experience working with numerous technologies, as well as a deep understanding of proper code documentation, and feature migration. This complete skill package may not exist on every team, and if it does, organizational structures and hierarchies might make progress especially arduous. Many companies might find that bringing in outside resources to guide their teams with not only expert level technical training and augmentation, but also team building mentorship, and a heightened capacity to unite c-level management with their web development teams, might help them better reach their technical goals, and establish better strategies for their future updates.

Annual codebase maintenance can cost up to 10% of the initial cost of development. For out of date codebases, these costs can create long term budgetary problems for your organization, which will only grow as the utilized technologies grow more and more antique. Though you have a number of options when approaching legacy code, This Dot Labs encourages many companies to consider either migrating most of the major functionality components, or rebuilding the entire codebase in order to reduce long term maintenance costs, afford more opportunities to employ cutting edge technologies, and reduce the onboarding speed of new developers.

If there is ever anything that This Dot Labs can do to help you translate your legacy code into a tool for strengthening your teams, leveraging the resources of past expertise, and creating a roadmap by which we can strengthen or rebuild your code, please don’t hesitate to reach out.

This Dot Inc. is a consulting company which contains two branches : the media stream and labs stream. This Dot Media is the portion responsible for keeping developers up to date with advancements in the web platform. In order to inform authors of new releases or changes made to frameworks/libraries, events are hosted, and videos, articles, & podcasts are published. Meanwhile, This Dot Labs provides teams with web platform expertise using methods such as mentoring and training.