There’s a medical term called “guarding” where a patient reflexively (possibly unconsciously) tenses or flinches when touched to avoid irritating an internal organ that hurts or is injured. Guarding is such a reliable reaction that it’s actually used as a diagnostic sign to indicate that something might be wrong with you.
The same thing happens with software.
Have you ever watched a team go to ridiculous lengths not to touch a certain piece of their application? That application guarding is a code smell. It means something inside is sick and needs to be treated, not ignored.
Here are two examples from projects I’ve worked on:
1) We had a company-wide XML standard for exchanging domain-specific information between departments and applications. As you might expect with such a thing, we were careful to make sure the standard was well thought out and that it changed in a controlled way so that application teams weren’t surprised by sudden breaks. But when we had the governance process around changing the schemas wrapped up too tightly, individual application teams started stuffing inappropriate values into inappropriate fields and agreeing to implied “schemas” amongst themselves. They would go to great lengths not to have to approach the central team that managed the schemas. This “guarding” around schemas was a symptom that the governance process (and in some cases, the schemas themselves) needed help.
2) I once worked on an application that had a Visual Basic 6 front end and a Java 1.3 back end. Back then (1999) people were still seriously trying to use CORBA, so we tried to use CORBA to talk between the front end and the back end. The problem was that Visual Basic had no way of talking CORBA, so we implemented a thin, client-side layer that talked CORBA and wrapped it in COM, using Microsoft Visual J++ (remember that?) which had proprietary extensions for making a Java object behave like a COM object. The whole thing was incredibly convoluted and the technologies involved had nothing to do with the technologies involved in the rest of the project. So, over time, when the signatures of the service methods really should have changed, application developers stuffed implicit switches and flags and values into existing signatures instead because they were afraid of the J++/COM/CORBA layer and didn’t know how to change it. Eventually, that application team fixed the underlying “sick organ” and replaced the whole layer with XML-RPC.
So, in summary, if there’s a part of the application your teams goes great lengths to avoid, maybe you have a sick organ. Time for a transplant!