Advice from G.K. Chesterton

Two common situations: an organization has all sorts of bureaucratic procedures, a legacy code base includes lots of ugly old code. Both seemingly serve no purpose.

The inclination is to streamline the process by getting rid of those procedures, and to improve the code base by cleaning out all that old code. It might even work for a little while - while everybody is excited about the change, remembers how the situation was before, and remains on their best behavior. Yet, later on, the problem comes back.

A lot of the time the seemingly useless processes and code were there for a reason. Sometimes the reason is no longer valid, or good, and it is in the organizations' interest to reform. But occasionally the reason is no longer visible because, well, the process in place took care of the problem. Which means that should that process be streamlined away, the problem will show up again.

It is a little easier when dealing with code. Tools will analyze dependencies and find whether the code is ever run by the system. Good unit test and regression coverage will help to find bugs introduced by changes. However, nothing replaces having an understanding why this particular piece of code was created in the first place, what problem it was trying to solve, and whether this problem is still around.

Original article Meteuphoric: Protect the seemingly useless