The moment you write a line of code, it becomes legacy. If the cumulative mass of that legacy is small, then there is correspondingly little inertia; if the cumulative mass is large, then there is considerable resistance to change. Refactoring becomes more and more critical as mass increases, because it drives a software-intensive system to intentional simplicity, thus creating a more frictionless surface. — Grady Booch
Grady Booch defines Software Archeology as “The recovery of essential details about an existing system sufficient to reason about, fix, adapt, modify, harvest, and use that system itself or its parts.” (for instance in his presentation about the topic which can be found here Folie 8). Refactoring old code is indeed a bit like archaeology: you deal with lost artifacts where the builders and architects are unknown, trying to figure out the purpose. The software developer digs and sifts through millions of lines of code and hundred layers of abstraction, like the archaeologist who digs and sifts through a million lines of dust and dirt. Sometimes you find pearls of engineering or discover what the engineers must have thought. But most of the time you are digging in the dirt and understand nothing.