Let’s pretend for a minute that you aren’t a software developer, and that you are a doctor. A patient comes in with the following symptoms:
- Trouble walking
- Redness and swelling around a wound on the leg
- Give the patient a band-aid, pain killer, a walking cane, and a cold bath?
- Investigate and clean the wound, administer antibiotics, and recommend rest?
Sometimes in software development, we see things just like this. We see the symptoms of a deeper underlying issue, but we get fixated on solving or fixing the symptoms rather than the underlying cause. Let’s take a more software related example.
A customer occasionally sees a database error. Do you:
- Wrap everything in a try/except and display a nicer error message (or hide it altogether. It’s not like the customer can do anything about it, right)?
- Investigate the command that was causing the database error, and fix the underlying problem that allows the error to happen in the first place?
It seems totally obvious what the better solution is in this case, but so often things are patched with duct tape, chewing gum, bailing wire, and band-aids. After a while, it becomes a disgusting mess that no one wants to deal with it. At that point (or well before that point!) developers start crying for a re-write or a refactor. A good case of “refactoritis” can be a sign that things haven’t been properly fixed along the way. Maybe a rewrite or refactoring is necessary. Maybe it isn’t. But either way, the temporary solutions need to stop, and underlying issues need proper investigation.