Chesteron’s fence is a principle that, in essence, states the following:
Never take down a fence until you understand why it was put up in the first place.
Apologies to G.K. Chesterton, who put it so much more eloquently in The Thing (the book, not the movie).
This principle manifests itself in our codebases all the time.
Ever try to delete code you thought was unused? Ever bring down production doing so? I have.
Ever refactor code without tests around it (or even with characterization tests around it) and realize later that you missed a code path? I have.
Ever change a setting in a database, only to realize the system depends on that setting, even though it was marked as unused? I have.
All of these are Chesterton’s fence examples. Put simply, it’s really easy, and almost certain, for us to not understand the system once it’s released into the wild. It grows on its own, adapting to changing circumstances, and a lot of times those circumstances make the code look sort of like this:
Any time a new developer comes into the system, they may be tempted to remove that gate. After all, it’s not doing anything, right?
Well… How do you know?
The trouble is, you don’t and you can’t know with certainty, not without Test Driven Development. Delete some code and if all the tests still pass, the code wasn’t needed.*
Funny enough if you use TDD, you’ll be regularly deleting code enough to not have to worry about Chesterton’s fence.
There is immense value in this approach for your team. When production bugs are as easy as deleting a required setting that people thought wasn’t being used, it’s critical to ensure you have a style of development that keep these freak, costly accidents from happening in your code base. Yes, your code may just be an internal financial dashboard for an insurance company; but if that dashboard goes down, can your insurance agents still sell insurance?
*there are a lot of ins, outs, and what-have-yous with this (like using a FauxO style of TDD so you don’t have to necessarily worry about lots of integration test paths; but still having integration tests to cover the boundaries, like network IO, disk IO, and the user interface)
P.S. I offer virtual team TDD immersion training for .NET teams. During this time when your team may be experiencing a lull due to global events, think about using this training as a way to keep your teams sharp and ensure you can deliver software reliably and consistently to your stakeholders. Learn more at https://www.doubleyourproductivity.html/paid.html