Why Code Scents?

Okay, I admit it, Code Scents is kind of a cheap pun. But there is a point behind the oh-so-clever title.

Code Scents is a play on the term "code smell" used originally by Kent Beck on the C2 Wiki to describe the feeling you get when you encounter troublesome code. In my experience, repetitive, overly complex, or clever implementations often stink the most. Following the smell of your code provides a hint of where something may have gone wrong in the system.

The ability to "smell code" is an instinct for refactoring that develops with time and practice, and it takes a certain amount of humility and self-awareness to get good at it. The point here is that good programmers are aware of the quality and context of their code as they are writing it and they strive for simpler, more elegant object designs. It's not about coming up with the perfect solution right away, but rather refactoring the system constantly, allowing it to evolve over time based around the needs of the user.

Despite how code smell has been picked on by critics of extreme programming, I like the concept because it suggests an element of intuition in what is often regarded as a terribly logical occupation. Of course thoughtful problem solving is an essential part of the job, but it's also important for programmers to be aware of the way a design unfolds as it is implemented; to have a sense of the code they're writing. It suggests the importance of simplicity in software development, and emphasizes the role of refactoring in the agile design process.

Word play aside, code sense is skill I'm still nurturing, but the satisfaction of coming up with a succinct metaphor or new design approach for my code always makes the refactoring effort worthwhile.