> Here, I propose Scott’s Law: never put order in a system before you understand the structure underneath its chaos.
Previously formulated as Chesterton's Fence [0], among others.
There's definitely a blind spot in software for the general principle that you should understand a thing well before you decide to remove it. Anyone want to propose some theories on why disregard for an extant body of work tends to plague software so extensively?
Because we suffer from the attitude that we don't have to understand a thing, as, say, reading the article might lead to, before attempting to correct it. ;)
It wasn't really intended as a correction -- more just an addition -- but I didn't feel like clarifying just to save a few imaginary internet points. Apologies to anyone who interpreted as attempting to correct an article I didn't even read. :)
> Anyone want to propose some theories on why disregard for an extant body of work tends to plague software so extensively?
Removing stuff isn’t restricted to software practitioners but there’s no need to reach for a flashy theory for something that can be adequately explained by human nature, in this case hubris.
Hubris is bound to manifest in any situation when a person with incomplete understanding of the situation, acts like they ‘know best’.
Previously formulated as Chesterton's Fence [0], among others.
There's definitely a blind spot in software for the general principle that you should understand a thing well before you decide to remove it. Anyone want to propose some theories on why disregard for an extant body of work tends to plague software so extensively?
[0] https://www.chesterton.org/taking-a-fence-down