Fix the Real Problem

The road to spaghetti code is paved with a thousand sloppy fixes.

The value in a variable is wrong, so someone fiddles with it close by to where they found the problem. From a stack perspective, this is way up in the call tree, so we’ll call this high. Somewhere buried down in the calls there are other places where the bug could be fixed. We’ll call the one a farthest down, low. Fixing a bug high, instead of low, is a mistake.

If you are going to fix the code, you need to fix it at its lowest possible location, not the highest one.

Why?

If the code is used in only one place, it doesn’t make a difference where you fix it, high or low. But, if you fix it high, and later someone else reuses the same call, which is what you want, then they’ll have to fix the bug too.

If the code is used in multiple places, and you fix one instance of it only, then the other places are still bugs. If you fix each one independently, you have wasted a lot of time.

With high fixes, if there are a lot of them, the usage of the call varies all over the place. It is hard to clean up, and it is hard to refactor. If this occurs once the mess is not too bad, but if this keeps reoccurring then it is a huge mess.

Once it is a huge mess, people often get frustrated and start siloing the calls. When they do that, they are relying on duplication of code to get beyond their own disorganization, but while it may seem to be a good idea initially, it will only get worse.

Fix the bug as low as possible, always. If that changes a few of the calls, then fix those too. Do it properly and there will be far fewer problems going forward. Do it poorly, and the code will explode into spaghetti, really quickly. Or as they used to say “a stitch in time saves nine”. Works for both clothing and code 🙂