You hear them all the time in software development shops, these common phrases that always get a laugh in my presentations because people are so familiar with them. And while we hear them and maybe even say them ourselves, we seldom take a closer look at the underlying issues with our software development principles and practices that cause us to hear and say them so often. Let’s take a look at some of the more common phrases and see what issues they often reveal and what Agile practices might help alleviate them.
“It Works on My Box.”
This is by far my favorite because I hear it (and I admit that I say it) quite a bit. It is most often uttered by a developer who is told some feature they authored is not working on the server or another developer’s machine. It is so common that there are t-shirts and even a song. Very funny but it can be indicative of several issues:
- Developer Apathy – Often the phrase is accompanied with a shrug as the developer walks away. Not a very good team effort to drop the ball like that and leave someone else to pick it up and try to figure out what is wrong.
- A Poor Definition of Done – If your process allows developers to simply get something built and tested on their personal machine, then you will hear this phrase more than you would like.
- Siloed Development and Late Integration – Often teams split up tasks and go away for long periods of time to write code in a vacuum, coming together late in the process to start seeing if what they have written separately will work when integrated together. Which it rarely does right off the bat.
So what Agile principles and practices can help prevent you from hearing this phrase over and over?
- Continuous Integration - Since CI builds (and tests hopefully) software that is checked in on a separate environment, these types of issues are caught earlier. If you implement more robust stop gap measures such as TFS 2010’s new gated check in feature, you can proactively prevent bugs of this type from even getting into the source on the server. I personally think this is one of the low hanging fruits of Agile (more specifically XP) since you have to build, integrate, and deploy the solution sometime anyway, this just makes you do it sooner and more often. There are many good solutions out there besides TFS such as Team City and Cruise.
- Clear Definition of Done – Even though there is an implicit definition of done most developers have in their heads, you should sit down with your team and clarify what everyone expects to have been completed when someone claims a certain coding task is “done”. I suggest writing in down on a big sheet of paper and posting on the wall in the team room. So when someone says “Oh yeah, that’s done.” you can point to it and ask “Really?”. This can also help remove another common developer phrase from your teams vocabulary: “Done done.”
Stay tuned for our next entry: “Don’t Read the Architecture Documentation, It is Not Up To Date Anymore.”