My analogy is imperfect, sure. And sometimes software is so bad that it should be tossed out. I mostly see that when business requirements have changed so much

My analogy is imperfect, sure. And sometimes software is so bad that it should be tossed out. I mostly see that when business requirements have changed so much that the software is a drag, not adding value. Or a vendor went out of business (ask me about the companies left holding the bag because of SCO), or something else in the IT landscape caused the code to become obsolete and unworkable. But in my experience (and this is what I do) those cases are relatively rare. In the last 10 years freelancing I've taken on close to 40 projects, I've only told two customers that they should start over. In both of those cases we weren't looking at crufty 20-year-old code. The software was fairly new, just poorly designed or implemented (WordPress is not a great platform for everything, folks). One project was a pile of random piecework from low-price contractors hired online -- no conceptual integrity. Talking to other programmers who do the same kind of work I do, I get the same anecdotal evidence: most software systems are maintainable despite the best efforts of programmers to make things too complicated and obscure. Rather than rewrite from scratch it's safer to refactor bit by bit, fixing a defined set of problems little by little. That keeps your chance of success high and customer risk low. Try to remove dependencies rather than add more. Carefully get things like version control, testing, tooling in place, but don't get carried away, some code resists retroactive unit tests and you shouldn't be breaking stuff just to make it fit your toolchain. Resist the urge to "refactor" everything to suit your aesthetics or received wisdom about how code should look. You're right that it's more common to see features added on and the worst bugs addressed. That's usually because the core of the system is solid and doesn't need a lot of maintenance. It can also happen when the core is a black box no one understands and the programmers are afraid they'll break it. Most important is to listen to the customer but don't believe everything they say -- customers often can't describe in detail how their own business processes really work. Don't assume that just because the code is written in an old language or isn't based on OOP or doesn't have unit tests that it's shit -- you can blind yourself to good design principles that aren't in fashion anymore. And have some humility -- it's unlikely you actually know how to rewrite a non-trivial application from scratch and get a better result than what the customer already has, unless it's an unusable pile of goo already.