Something I'll call Milito's Meadow [1]. Start with a clean slate. Everything goes: fences, farmhouses, roads… Down to the bare earth.

Then build up again from scratch. Likely you will in fact put a fence here or there—but of course you'll know with certainty why it is there. (And more times than not, there will be fewer fences when you are done.)

[1] Naming this for a friend who taught me about fence razing.

▲

quietbritishjim 4 days ago | parent | next [-]

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

▲

BoxFour 4 days ago | parent | next [-]

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!

	▲	quietbritishjim 4 days ago \| parent [-]
		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).

▲

RetroTechie 4 days ago | parent | prev | next [-]

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

▲

BurningFrog 4 days ago | parent | prev | next [-]

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.

▲

tshaddox 4 days ago | parent | prev [-]

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?

	▲	quietbritishjim 3 days ago \| parent [-]
		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).

▲

bombcar 4 days ago | parent | prev | next [-]

A ground-up rebuild can be wonderful, but something is lost in those US plaster-planned cities that attempt to imitate Florence or other EU cities; something about organic growth that is very hard to replicate ex-nihilo.

This likely doesn’t correlate to code as much.

▲

stephantul 4 days ago | parent | prev | next [-]

Extreme programming in a nutshell. I like doing this to features: build it, then take it down and rebuild but better.

	▲	jpitz 4 days ago \| parent [-]
		"Plan to throw one away. You will anyway."

▲

asplake 4 days ago | parent | prev | next [-]

Reminds me of Ackoff’s Idealised Design [1]

[1] https://en.wikipedia.org/wiki/Interactive_planning#Idealized...

▲

cwmoore 4 days ago | parent | prev | next [-]

Unfortunately, before the fences are down you are in jail, and with you, it stays where it was.

▲

simondw 4 days ago | parent | prev [-]

Sounds like a very expensive and time-consuming way to build something that won't work very well for a while. Is that the point?

	▲	JKCalhoun 4 days ago \| parent [-]
		It takes technical debt head-on?