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:
In the matter of reforming things, as distinct from deforming them,
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:
Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.
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.
Not particularly. This is more about unexpected/unintended consequences following from changing something you don't fully understand. The thing you want to change may very well be broken, but if you try to fix it without understanding why it was put there in the first place, you may not fix your problem — or, worse, may un-fix the original problem.
