Smell is a Smell
Published on Feb 13, 2015 by dix.

If you have worked in the software industry for any amount of time, you have likely heard something referred to as a “Smell”. Whether it be a piece of code, a development practice, an organizational practice, or really anything, “Smell” is the easiest criticism for a software developer to level against a thing he/she does not like. I want to discuss the origin of this usage, why I find it overused, and how to improve the situation.

According to Martin Fowler, “Code Smell” “was first coined by Kent Beck while helping with Fowler’s Refactoring book”. ¹ Fowler defines “Code Smell” as “a surface indication that usually corresponds to a deeper problem in the system.” He continues on to note that a “Smell” should be something that is quick to spot. It can point to a deeper problem in a code base, but does not necessarily. It is not sufficient to identify the “Smell”, but also to look for it’s root cause and determine if the “Smell” is indicative of a greater problem.

What makes the presentation of “Code Smells” in Refactoring so effective is that each “Smell” is followed by discussion of the larger problems that it is likely indicative of. Additionally, the author presents refactorings that can be used to fight the “Smell”. For example, the “Middle Man” is a “Smell” that is recognized when a object only delegates to another. This “Smell” suggests that the delegating object provides no value and should be removed. Three refactorings are suggested to alleviate the problem.

The author of Refactoring relies on a wealth of experience in presenting “Code Smells”. When a “Code Smell” is identified in Refactoring, it means a great deal more than “looks bad at first glance”. It instead means “We have seen this easy-to-identify problem many times before and have determined that it is often related to this specific underlying issue; here are specific tools to fix the problem.”

Outside of the realm of “Code Smells”, we do not have these same foundations. For that reason and others, I think we should consider the over-usage of “Smell” a “Smell”. It meets all the criteria: it is very easy to recognize and can indicate a problem where-in engineers are too fast to criticize without identifying root causes and possible solutions.

I believe that it is far too easy to decree something a “Smell” and simply move on. The burden of proof for something’s “Smell”-worthiness is too low. I believe that it is a way to criticize without having any need to supply justification. I believe that we can do better than decreeing something a “Smell” and then dropping it.

Some might ask, “What is the harm in this beyond annoying you personally?”. I believe that the overuse of “Smell” leads to a culture of negativity and un-constructive criticism. I believe that stopping at declaring something a “Smell” without further investigation prevents people from learning and understanding the process of making difficult tradeoffs in designing systems, processes, and organizations. Finally, I believe that it leads to faulty decision making. The weight of “Smell”-accusations can add up to such an extent that well considered trade-offs are ignored.

So what should one do instead. If you identify a “Smell”, don’t just say “This might be a smell” and leave it there. Commit to examining the source of the “Smell” and determine whether or not it’s an actual problem. If it’s indicative of a problem articulate what that problem is and begin to work on a solution. Record this organizational/process “Smell”, note what larger problem it was indicative of, and document its solution.

If we as an industry commit to this kind of close inspection of our problems, we will all be better off.