Chesterton’s Fence in I.T. Services
I was talking to some friends recently about the idea of Chesterton’s fence. If you have never heard of it, this idea comes from G. K. Chesterton’s 1929 book, The Thing, in the chapter entitled, “The Drift from Domesticity.”
“In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer, “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.” – Wikipedia
In other words, if you see “a fence going across a road,” don’t just assume that it shouldn’t be there and tear it down, or you might soon discover that there was a very good reason why that fence was there. History is full of examples of negative outcomes that have resulted from the failure to understand this admonition.
Now, you might say to yourself, this is all very well and good, but what does this have to do with IT services? The answer is: plenty! I cannot tell you how many times I have been working on an IT project and have come across a preexisting configuration that seemed totally foolish or obviously incorrect. When I was less experienced, I might have even gone ahead and removed said configuration, only to find out later that I had broken something somewhere else in the network as a result. Upon investigation, I have often found that what SEEMED like a foolish configuration was simply the only expedient way to solve some business problem with unusual constraints. Maybe some strange looking solution had been hacked together to make two otherwise incapable systems talk to one another. Or perhaps the business didn’t have the budget to upgrade to the latest version of a product and a kludgy workaround was the only way to make the system work. There are many reasons why a stupid looking configuration might be in place.
So I have learned over the years to have a bit more respect for the IT folks who worked in an environment before me. Whenever I evaluate an IT configuration for a new client, I now take my time to understand WHY each component was put into place, before I rush about tearing systems out and replacing them. This is not to say that I am hesitant to upgrade and modernize. You might just think of this advice as saying, “Make sure that you have really, truly gathered ALL of the requirements being fulfilled by an existing system before replacing it.”
If you have an aging IT infrastructure and want to replace it without breaking any of your business processes, give us a call and let’s take a closer look at your systems together. Taking a bit of time to do a thorough investigation generally pays off.