Hacker News Reader

Comment by quietbritishjim | Hacker News Reader

This 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!)

View on HN

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!

Right. Chesterton's fence isn't "never remove a fence". It's "understand why it's there before you remove it". If you look and find out it's for a long-unsupported platform, go for it.

In practice, a mature codebase is likely to have a mix of now-useless warts and seemingly useless but actually essential elements, along with some that fall in the middle (most often, in my experience: attempts to fix valid issues but in a way that no longer makes sense).

> 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.

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.

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?

I'll admit the example is a bit sketchy. My dim memory is that Netscape's mistake was that their business model was charging for their product, which is not unreasonable but was doomed when Microsoft gave Internet Explorer away for free and included it in Windows (so you'd really have to go out of your way to find Netscape's paid alternative).

Reply on news.ycombinator.com