Legacy code: Chesterton Fence vs Ólafur’s yellow box
Here’s a rewritten paragraph in simple English: When I’m working on old code, I often come across something that just doesn’t make sense! In those moments, I ask myself: “Is this code like Olafur’s yellow box or Chesterton’s Fence?” You see, Olafur’s yellow box is when someone wrote weird code because they thought it was a good idea at the time, but now it’s confusing. And Chesterton’s Fence is when some clever person wrote something that might seem strange, but cleverly makes sense! By thinking about these two possibilities, I realize that there’s not just one answer — sometimes code can be weird on purpose!
Chesterton’s Fence
Imagine you’re on an adventure and suddenly, you come across a fence! Now, don’t just knock it down like a big bully! Remember, someone put a lot of effort into building that fence, so there must be a reason why it’s standing tall. You should try to figure out what the clever person who built it was thinking… “Why did they put it here?” Think about it for a bit, and only when you understand the reason behind the fence can you decide if it’s really blocking your way
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.
Ólafur’s yellow box
In one harbor, there’s a special box that’s been painted bright yellow. A long time ago, a man named Ólafur accidentally spilled some yellow paint on a grey box while painting the yellow lines. Instead of getting grey paint, he just painted the whole box yellow. And you know what? That yellow box is still standing today, looking happy and bright, being repainted yellow with maintains!
In the code
Chesterton’s fence will protect different people from solving the same problem multiple times. However, if you cannot figure things out about the code it will be filled with Ólafur’s yellow boxes.
Get Tom Nijhof-Verhees’s stories in your inbox
Join Medium for free to get updates from this writer.
So what to do if you find one; a piece of code without clear names or (good) documentation?
Git blame
If you are using version control software you can find out when lines were added or edited. Finding out the pull requests that changed it, the person who did, the tickets or issues added to, and the date it happened.
The worst I had was going back years with an author name I only read in an ‘in Memoriam’ message, but there was a ticket linked to the merge request so I knew what error was being solved by that code.
Trust the tests
Remove or refactor the code and let all the tests run (maybe even manual). The test that fails will help you to figure out what was doing.
However, we are not always that lucky to have tests covering it.
Write tests yourself
We write tests for the current behavior, without checking if the behavior is correct. Generative AI is very good for this. After we have those tests we can refactor the code or remove it to see what changed.
This will give us insight into what this code is doing.
Wing it
Sometimes the best thing is to just go for it and hope for the best. If somebody asks what you are doing, the phrase is “Given the experience I have with this code and similar code bases I have worked on, this refactor/removal should have an overall positive effect on the code quality” and hope there are no follow-ups.
Ignore it
Other times it might be better to ignore code. The risk and cost of breaking might be too high. So just accept your code will have a few yellow boxes and that is okay. The one in Iceland even became a tourist attraction: https://maps.app.goo.gl/uoEjZhqcpsBEbhw4A
Conclusion
In conclusion, navigating legacy code often requires discerning whether you are dealing with a necessary structure like Chesterton’s Fence or an arbitrary decision like Ólafur’s yellow box. By understanding the intent behind the code, you can make informed decisions about whether to preserve, refactor, or remove it. Utilizing tools like version control software, running and writing tests, and sometimes taking calculated risks can help you manage legacy code effectively. And remember, not every piece of confusing code needs to be changed; sometimes, accepting a few “yellow boxes” is part of maintaining a functional and stable codebase
