Chesterton’s fence from G. K. Chesterton’s 1929 book The Thing (in the chapter entitled “The Drift from Domesticity”):
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
I found this used as a parable for a rash rewrite of legacy software, where the original specifications and constraints are unknown.
The same article (“Exit the haunted forest” by John Millikin, https://increment.com/software-architecture/exit-the-haunted-forest/), where I found this, also mentions the story of Netscape, its (in)famously ugly code base and the ill-fated attempt at a total rewrite, as a parable for recklessly rewriting without need, specifically in the narration of Joel Spolsky (Apr. 2000): https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
The idea that new code is better than old is patently absurd. Old code has been used . It has been tested . Lots of bugs have been found, and they’ve been fixed . There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material ?
Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.