I was reading through a page on Ward's wiki about a book called How Buildings Learn. On the page was this quote from the book:
Use materials that smell bad when wet.
As the author of the comment pointed out, this correlates closely with Kent Beck's description of "code smells".
This got me thinking: how can you write software so code smells are obvious as soon as they appear?
I think the best way of doing this is to ensure that the entire codebase conforms to a high standard. This means refactoring constantly. If code smells appear in a system such as this, it should be obvious to any developer on the team and a simple task to fix this section of the code.
Keeping smells out of your code ties in with the "broken window" theory of Dave Thomas and Andy Hunt: allowing just one piece of smelly code can promote a philosophy that sub-par code is acceptable. Refactoring mercilessly could help to avoid this problem.
Another idea I've heard from David James is to use automated tests for code smells. Make it part of your build process to have a test that scans for common code smells. Smells like long parameter lists, long methods, switch statements and many others are easy to identify. Having this as an automatic process for developers to run will make the smells more obvious.
I'd like to hear other people's ideas on this topic. How can you make developers really retch when they see bad code? Is this enough to get them to fix it? Click on the link below to post your comments.
