Imagine that you bought a new house with a huge backyard garden and there’s this ugly high opaque fence in your garden. You’re eager to redesign the garden to your liking, and wish to tear down this fence. Before you tear the fence down in this thought experiment, stop and think about why it was put up in the first place. Perhaps it was to prevent wild animals from entering your premise, or perhaps it was to protect your privacy from nosy neighbours? Tearing it down before answering those questions could lead to disasters - in the former case, you could be attacked by wild animals.

I first heard about that analogy (paraphrased) when I was working at a hedge fund, where the CTO was talking about dealing with legacy code. It was during a period where we started rewriting code that was written a decade ago and the rewritten code sometimes broke existing systems. This was a warning for erring on the side of caution and resisting temptation by maintaining status quo when migrating over seemingly useless code. Often when we work on an existing code base, we have the urge to rewrite things to look “nicer” or be more “correct”. This can lead to deleting certain code that looked seemingly useless, just like the ugly fence above. However, without the original context on why the fence was put up in the first place, removing the code could cause the whole system to stop working.

To help your future self or colleagues, consider writing good commit messages and comments even though they may seem obvious at the time. In the thought experiment above, it was obvious for the previous owner to put up a fence because of the attacks but that context was lost when you bought it. What would have been helpful for you was plenty of signage around the fence to say it’s to keep wild animals out.