Making bad smells worse

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.

Portrait of Matt Ryall

About Matt

I’m a technology nerd, husband and father of four, living in beautiful Sydney, Australia.

My passion is building software products that make the world a better place. For the last 15 years, I’ve led product teams at Atlassian to create collaboration tools.

I'm also a startup advisor and investor, with an interest in advancing the Australian space industry. You can read more about my work on my LinkedIn profile.

To contact me, please send an email or reply on Twitter.