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.
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.
Extreme programming in a nutshell. I like doing this to features: build it, then take it down and rebuild but better.
Reminds me of Ackoff’s Idealised Design [1]
[1] https://en.wikipedia.org/wiki/Interactive_planning#Idealized...
Unfortunately, before the fences are down you are in jail, and with you, it stays where it was.
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?
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!)