Chesterton’s Fence

Chesterton's Fence

Often within Information Technology, we are working with IT Systems that were built by a predecessor and may not have been properly documented.  Members of your helpdesk staff and development teams will find processes in place that do not have an obvious function.  Caution should be taken before making changes; when the intended purpose is not clear.

Working with IT Systems that have not been documented.
  1. Always assume a piece of hardware or software exists for a reason
  2. Work to validate whether a system is in use before making changes
  3. Once you are aware of potential impact areas, schedule changes during low impact hours
  4. Always have a plan in place to rollback changes
  5. Document, document, document

The Full Scoop

The basic premise behind Chesterton's fence is that you should not make a change until you understand why something was done in the first place.  It comes from a quote in the 1929 book "The Thing" written by G. K. Chesterton.  A fence, for example, despite its age or condition was built for a reason; before tearing it down, you should determine who built it, why, and whether a new fence would need to be put up in its place.

Once you've worked in Information Technology for a while, no doubt you've come across hardware and software that did not have an obvious purpose.  The person who deployed it is likely no longer around, documentation is often scarce, and if its purpose or currently usage is not well understood; it could be very tempting to remove it.

Whether it is a line of code in a software program, or an old network switch sitting under someone's desk, assume it has a purpose.   It was likely not put there merely for fun.  Take some time to research why it exists, ask around, and work through what the potential risks would be in removing or replacing it.

Once you have a solid grasp on what could be impacted by its removal, seek a consensus from impacted stakeholders on a plan for its removal or replacement.  If there is a real concern that a change could break a critical process, have a rollback plan.  A rollback plan is how you would unwind the changes you had made, and could involve taking backups, swapping out equipment; essentially putting "Humpty Dumpty" back together again.

Show your customers the value going forward in properly documenting their system.  Even small business networks can gradually become fairly complicated over time.  It is easy to forget why something was done, your system documentation should be in a accessible place that is transferable from one employee or vendor to another.

Strive to simplify rather than merely add to what previously existed, and over time you will find your IT System becoming easier rather than harder to maintain and support.