alt Hacker NewsThis is addressed by the classic article by Joel on Software (which is apt, as it's a classic mistake):
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
To rephrase in the language of this conversation, he answers: why are there all those fences there?
> 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.
(Yes the references are a bit out of date. The article is from over 25 years ago!)
Replies
> which is apt, as it's a classic mistake
Was.
Look at it as a house (which already exists). There will be defects. Some big, some small. Some obvious, some hidden.
Maybe the exterior looks bad, but the interior is fine. Give it a paintjob.
Maybe it could use a new kitchen but otherwise it's fine. Do the kitchen.
Maybe it's fine but the family living in it could use some storage space. Add an extension or put up a shed.
Or maybe its foundations are crumbling, walls are cracked, roof is leaking everywhere, doors are slanted, and thieves ripped out all the copper piping. Tear it down & rebuild (developers seem to prefer this option).
But your job is not to follow the same approach wherever you go. It's to have a good look around, get a feel for the place, and decide what should stay & what needs fixing.
That can include fundamental design aspects. Why was it built that way? Is it time to port to a new platform?
Joel Spolsky wasn't wrong either. Re-developing a sizeable project is a big job, and comes with significant risk for its users. But the metrics have changed.
LLMs have reduced the cost of rebuilding a lot. Not the risks. Choose wisely.
Haven’t there been successful rewrites of nontrivial applications? I’ve always been skeptical of Joel’s Netscape example. Was the rewrite really the mistake? Couldn’t the mistake have been making an application where no one knows how it’s supposed to behave?
That essay really shook me into understanding things I had never thought of, and I've been better at my job ever since.
I remain grateful to Joel for the insights!
In 2026, test suites can and should handle much of this uncertainty. If Nancy wrote a good test for her fix, we can rewrite and refactor with much less fear and risk.
Actually, I think the old references are relevant. Sometimes those bug fixes and workarounds no longer matter. Windows 95 and Internet Explorer are long gone, we don’t need to architect our code base any longer to support them, but everyone’s petrified to remove the support for them.
Or in the language of fences, the fence might’ve been built for a herd of cattle that no longer exists. Raze away!