The concept of a legacy usually conveys permanence, value, and greatness. But what about in relation to your code? In this article, Jonathan explains how his team broke up with their legacy codebase, why it was necessary, and how your team can do the same. Written and read by Jonathan Solózano-Hamilton: https://twitter.com/jhsolor Original article: https://fcc.im/2FEuAcR Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:    The concept of legacy conveys permanence, value, and the greatness we bequeath to our children and our successors in the community. People make ludicrously generous donations to charitable causes to establish their legacy. They create eponymous endowments or buildings and strive to protect the name their children will inherit. It’s therefore striking that software developers have gotten their “legacy” so catastrophically wrong. Google “legacy,” and you’ll see the first definition matches what I’ve laid out for you here. It’s a definition that’s persisted since the 14th or 15th century. The second definition provides a shocking contrast: legacy. adjective (computing) “denoting software or hardware that has been superseded but is difficult to replace because of its wide use. Dictionaries around the internet agree with this definition. It applies only to the field of computing. We developers have managed to invert the definition of our own legacy in the historical eye-blink that is computer science. That’s almost impressive! If you’re an experienced developer, you’ve certainly been tasked with supporting at least one legacy system in your career. For the uninitiated, well — buy a lot of caffeinated beverages. I’m about to relate to you the brief story of our toxic relationship with our legacy codebase. I’ll then describe how we broke up with it, and what we’ve changed to avoid falling back into bad relationships with high-maintenance code. The Breakup It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul. Our predecessors had pushed code into production for years without writing a single line of documentation. In fact, some of it wasn’t even in source control, as we later learned. But that’s another story. I’m sure you’ve seen gems like this before: ... hundreds of line of incomprehensible code // TODO: Fix this bug!!! ... hundreds more lines in the same method, no idea where or what the bug is That is the approximate ratio and quality of the only documentation we had on the project. I wasn’t exposed to direct sunlight again until April, and I’d had enough. It was time for a break-up. The importance of documentation In his book “The Art of Unit Testing,” Roy Osherove defines legacy code as any code that doesn’t have tests. He was an optimist. I more loosely regard as legacy any code which contains more technical debt than the time it took to write. As our organization had, many development teams fall into the trap of instant-legacy code: code that already fits the “legacy code” label at the time of release. In my experience, documentation is the most important aspect of avoiding such legacy code. I have yet to meet a developer who loves the idea of documentation. On the other hand, I also have never met a developer who loves crawling inside the skull of a stranger to reverse-engineer a legacy implementation without any documentation. As they say, breaking up is hard to do. But in this case, I promise it will be worth it. So let’s get started on converting your legacy into something you’ll be proud to bequeath to your successors. Let’s get documenting! Our approach: four layers of documentation We created, and began rigorously following, a four-layer architecture for documentation. We maintain three layers of persistent documentation for the project through its life-cycle. We also communicate through one layer of ephemeral documentation during our release management process. The three persistent