Why the ugly code you want to delete is ugly on purpose

This is the piece to hand to anyone who opens a planning meeting by proposing a rewrite. It is from 2000 and it has not aged, which is itself evidence about how little the underlying dynamic has changed.

The core claim is uncomfortable and correct: legacy code looks worse than it is. Every awkward branch and unexplained condition is usually there because something broke once, in production, for a real customer, and somebody fixed it under pressure. Delete the file and you delete that record. The new version will be cleaner and it will rediscover the same bugs one at a time, in front of users.

For commercial plugin and SaaS work this is not an abstract argument. An install base you do not control cannot be migrated on your schedule, and a rewrite means running two systems until the last user moves, which is usually longer than anyone plans for.

Worth pairing with the strangler fig entry in this log: Spolsky tells you why not to rewrite, Fowler tells you what to do instead. Read in that order they are one argument rather than two.