A code smell is a surface indication that usually corresponds
to a deeper problem in the system. The term was first coined by Kent
Beck while helping me with my Refactoring
book.

The quick definition above contains a couple of subtle
points. Firstly a smell is by definition something that's quick to spot
- or sniffable as I've recently put it. A long method is a good
example of this - just looking at the code and my nose twitches if
I see more than a dozen lines of java.

The second is that smells don't always indicate a
problem. Some long methods are just fine. You have to look deeper to
see if there is an underlying problem there - smells aren't
inherently bad on their own - they are often an indicator of a problem
rather than the problem themselves.

The best smells are something that's easy to spot and most
of time lead you to really interesting problems. Data classes
(classes with all data and no behavior) are good examples of
this. You look at them and ask yourself what behavior should be in
this class. Then you start refactoring to move that behavior in
there. Often simple questions and initial refactorings can be the
vital step in turning anemic objects into something that really has class.

One of the nice things about smells is that it's easy for
inexperienced people to spot them, even if they don't know enough to
evaluate if there's a real problem or to correct them. I've heard of
lead developers who will pick a "smell of the week" and ask people
to look for the smell and bring it up with the senior members of the
team. Doing it one smell at a time is a good way of gradually
teaching people on the team to be better programmers.