Comment by CocaKoala
11 years ago
No; "If it's not broken, don't fix it" boils down to that if something is acceptable, you shouldn't spend time or energy messing with it.
This is more along the lines of "Not understanding the purpose of something does not mean that it doesn't have a purpose". If you don't know why the fence is there, don't take it down; it could be doing something you don't know, and taking it down would destroy some existing relationship that you were unaware of. If you can thoroughly explain why the fence exists, why it was put there, then you can think through the ramifications of removing it and make sure that whatever solution you implement in place of the fence will fulfill the same functionality.
I disagree. This is a form of "Not broken; don't fix." Though I'd probably classify it more as a corollary, or the pseudo-contrapositive, "If it has been fixed, don't re-break it."
In software jargon, I might also paraphrase it as "Never optimize before profiling."
You're already thinking too far ahead in the process.
This isn't about what to do with a problem - this is just saying that if you wish to fix things rather than break more things, you need to understand the system before changing it.
It starts:
Drawing an explicit distinction between re-forming and de-forming, I'd interpret reforming as meaning 'changing in an attempt to make better'.
And it ends:
It doesn't say "Then when you can come back and tell me you see the use, and it's wrong, you can destroy it.". It says you "may be allowed to destroy it" - that once you understand the system, then we can begin discussing changes.
"If you want to make a system better, you must understand it before changing it."
Or, to put it back into software... You're talking about how to deal with a bug in the code. Chesterton is saying that if you're trying to build a better application, you have to understand what the application is even trying accomplish at a high level before you can begin writing code.