Code “Smells”?
Explains the analogy
A curious non-native-English speaker asked about the “code smells” analogy. It didn’t make sense to them. Here is my response. (This is a quick one because I’m at the World Series of Poker at the moment.)
Sometimes code works but it will be hard to understand and safely change later. The code makes money by working but loses (future) money by being hard or unsafe to change.
Some programmers don’t distinguish between code that works and is easy to change and code that works and is hard to change. “It works, that’s all that matters.” Working now and changing later both matter, are both ways programmers create value. Only creating half the potential value is wasteful.
To teach the difference between these 2 situations, my friend Massimo Arnoldi used the analogy of “smell”. Food might still be okay to eat if it smells bad but smelling bad is a warning. It’s also a warning of future problems. If it smells bad today it is going to be poison tomorrow.
Does that help?
When I first read this analogy, accompanying it was the diaper metaphor: "If it smells, change it." I guess I found that sticky enough to remember it after about 25 years.
When the analogy fails, I fall back to "design risk". This gives me a chance to describe the difference between a risk and a problem. That usually helps.
The trouble with design risks seems not to be unique to design: it's easy to ignore risks, it's often hard to quantify the probability or cost of failure (sometimes both), and so the most common reaction is to do nothing and hope for the best. Humans don't plan well for unpredictable future events. :)
Or another pov is "technical debt". Just like code "smells", it compounds interests and gets worse over time.
Love the statement "If it smells bad today it is going to be poison tomorrow." It reminds the dreading consequence of bad codes left unchecked.