Comment by logfromblammo

11 years ago

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

1 comment

logfromblammo

nucleardog 11 years ago

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.