Agile lessons learned #9: Skunk Code

After a few months of Agile coaching things were starting to look brighter over at FreeFall inc. The Agile process was slowly but surely setting itself into place. Problem was, even though the team was pumping out an all out effort, their capacity to deliver was shameful. Tim had managed to convince FreeFall to hire Andrew, an Agile developer to give more technical coaching to the team.

“Man, I can’t believe this. The build machine is dying on me again !” Shouted Andrew
“Again!? What did you do ? ”
“I’m running the analyzer on our code. The code is so bad that ALL the code analyzers are dying on me”
“You’re running this on a 486 with floppies or what?” Asked Tim.
“If only I was. This machine is state of the art. Cost them a fortune. Man, it really looks like we have a serious case of skunk code here.” said Andrew

“Skunk code ? What’s that?” asked Tim
“Well you know some animals have defense mechanisms more evolved than others. The skunk for one, well, it just plain stinks. Most of it’s defense comes from just plain stinking so bad you won’t dare approach it.”

“I see. How does it relate to code ? ”
“Well you see, code usually starts with the best intentions. Then people introduce small flaws here and there.”
“Ever heard of the broken window principle ?”
“Can’t say I have.” said Tim perplex
“Well it’s a pretty simple theory. You break the window of a building and don’t fix it. For some reason, people who come next will notice it and take less care of the rest of the building. Within a year the place might actually start to fall apart.”

“Interesting, looks like what we have here. How does that relate to my skunk smelling code though ? ”
“Well you see, at some point the code base will contain so many code smells, people will be so repressed by it that nobody will dare touch it to fix it.”
“It thus becomes protected from ever being touched. Just like a skunk.”

“I see. What should we recommend to the client ?”
“Well for one they could stop adding more smells to this mess.”
“Any new code has very little reason to be messy.”
“How could they prevent that ?” – Asked Tim
“Behaviour Driven development or Test Driven Development properly applied should help a lot.”
“Take Cucumber, GreenPepper, xUnit, Rspec or whatever else you can think of and learn how to use it and why.”
“Pair programming should also be mandatory on most if not all coding activities. Try it out. Most people can’t go back to their old ways once they try it”
“Running the analyzers on the code can also give a hand, although it cannot replace the above two practices. Give a look at Sonar and the likes and find out what can help you or not.”

“That’s nice. How about the existing code ?”
“Well that’s gonna have to wait till I get my build machine running properly.”

Nicholas Lemay