We will always have legacy code because most software is writen to satisfy business requirement, and those requirements change over time. Except for hobbyists a

We will always have legacy code because most software is writen to satisfy business requirement, and those requirements change over time. Except for hobbyists and academics, software is not written with advance knowledge of every eventuality. From a business point of view good software adapts to change. Those adaptations may make the code more "legacy" or icky to future developers, but it's always a cost/benefit tradeoff. Software is not the only technology that turns legacy and needs refactoring. Have you ever done a significant remodel on a kitchen or bathroom? Did you curse the original plumbers and electricians for not anticipating you would tear a wall out and move the sink? No. You factor those costs into the job, expecting that some things will not be as easy as they first appear. If you hired a contractor to remodel your bathroom and he saw "legacy" plumbing that made the job harder, would you let him tear the house down and start over? Programmers tend to think of software very narrowly: the things they value are performance, an abstract notion of elegance, how impressed their peers will be by the code. They may try to anticipate future requirements but they risk violating the YAGNI principle if they get carried away (to say nothing of overrunning the budget and schedule). The people who pay for and use software have a different set of requirements. In most real businesses the data that runs the business, usually living in a relational database management system, has more long-term value than the application software. Data has a longer lifespan than software in most applications, too. Yet many programmers who bang the "legacy code is shit" drum give very little thought to data integrity or the long lifespan of critical business data. Sometimes legacy code is crap that has outlived its usefulness, and is now too expensive or dangerous to keep tinkering with. More often the legacy code works and isn't really that bad, even if it uses spaces instead of tabs, or has funky variable names, or isn't written in a cool language. Programmers need to step back from their own fashions and prejudices and spend some time figuring out the legacy code and how to fix and refactor it. Almost all of my consulting clients come to me after they've been told by three or four other consultants that their code is so bad it has to be thrown out and rewritten (in some cool new language). That is almost never necessary in my experience. I've written more about maintenance programming on my blog.