A code smell is, in Martin Fowler’s words, a surface indication that usually corresponds to a deeper problem in the system. The term captures the idea that certain patterns in code, while not bugs in themselves, often signal that the design has gone wrong somewhere underneath.
Fowler stresses two important qualities of smells. First, they are deliberately easy to spot quickly, or “sniffable,” so that even a developer skimming the code can notice them. Second, a smell does not always mean there is a real problem; it is an indicator that invites a closer look, not a definitive diagnosis. Classic examples include overly long methods and data classes that hold values but contain no behavior.
The term was coined by Kent Beck, who suggested it while helping Fowler write his book on refactoring. The two ideas are tightly linked: smells tell you where to look, and refactoring tells you what to do about it once you confirm a genuine design weakness.
Fowler notes that smells can be used as a teaching tool. A team might adopt a “smell of the week,” asking developers to find an example of a particular smell and discuss it with more senior colleagues, which spreads design judgment across the team.