Chesterton’s Fence

Chesterton’s Fence

Use Chesterton's Fence While Working with IT Systems

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. Learn about ‘Chesterton’s Fence’.

The Full Scoop

The premise of Chesterton’s fence, is to not make a change, until you understand why something was completed 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 previously made. It could involve taking backups, swapping out equipment; essentially your put “Humpty Dumpty” back together again plan.

Takeaways

  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!!!

Show your customers the value going forward in properly documenting their system.  Even small business networks can gradually become complicated over time. Forgetting why is easy. System documentation must be accessible and transferable from one Employee or Vendor to the next.

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

Fizen Technology

We love providing IT Support to our clients across the globe. Contact us to find out how we can help your technology thrive.