schedule pressure, the weight of history, or a lack of any better code to compare their efforts to, many people are writing legacy code. What is legacy code? I ve used the term without defining it. Let s look at the strict definition: Legacy code is code that we ve gotten from someone else. Maybe our company acquired code from another company; maybe people on the original team moved on to other projects. Legacy code is somebody else s code. But in programmer-speak, the term means much more than that. The term legacy codehas taken on more shades of meaning and more weight over time. What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don t really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts. That definition of legacy code has nothing to do with who wrote it. Code can degrade in many ways, and many of them have nothing to do with whether the code came from another team. In the industry, legacy codeis often used as a slang term for difficult-to-change code that we don t understand. But over years of working with teams, helping them get past serious code problems, I ve arrived at a different definition. To me, legacy codeis simply code without tests. I ve gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book: Code without tests is bad code. It doesn t matter how well written it is; it doesn t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don t know if our code is getting better or worse. You might think that this is severe. What about clean code? If a code base is very clean and well structured, isn t that enough? Well, make no mistake