"Put very simply: don’t destroy what you don’t understand." The Chesterton's Fence story has always bothered me. The moral puts all blame on the person challe

"Put very simply: don’t destroy what you don’t understand." The Chesterton's Fence story has always bothered me. The moral puts all blame on the person challenging the fence for not coming to the same conclusions as the builder. For the person building the fence, it's easy to assume that the purpose of your work is self-evident, but the truth is that it is hard for anyone else to put together the facts as you saw them, and it's harder still to reason the same way you did. So just thinking really hard about the reasons for the fence's existence will not necessarily lead to a correct -- or even desirable -- result. The story's moral may as well have been: "What I did is more important than what you want to do." Or: "Fear change." I'd rather see a dual lesson drawn from the same story: "If what you are doing is important, it's just as important to make it clear why it is important." This particularly applies in the context of software development, when a little effort to make the rationale of some code more clear can pay off over the dozens to hundreds of times the code must be read and rejustified.