We received over 80,000 unique hits to my blog post, “Fire your ‘best’ people, reward the ‘lazy’ ones”. Based on comments here and postings on other sites, it’s fair to say that many of you seem to agree that if you have too many people on a project that focus exclusively on troubleshooting, you’ve got a problem. I figured this post deserved further explanation…

I wrote this based on my experiences in working on dozens of projects as either a developer, tester, PM, architect or consultant. Some of the behavior that teams are rewarding will not lead to getting better software out the door faster. There’s no way you can prevent every problem from occurring on a project. However, when problems do occur, it’s important to ask two questions:

“Why did this happen?”

-and -

“What are we going to do to prevent it from happening again?”

That’s it. People need to troubleshoot issues, but they must also be asking these questions after fixing the problem. In the post, I pit the troubleshooter against the troublepreventer, but I go on to say that, without question, you need troubleshooters on your project. I am poking at the people that focus so much on troubleshooting that they forget to look to prevent the problem from occurring in the first place. The time you invest in fixing or preventing a problem should be based on risk. It’s probably not worth investing several days on preventing a problem from occurring if the likelihood of its occurrence is low and the impact of the realizing the risk is minimal. However, it may be worth your time if the likelihood is low/medium and the impact is high/severe (e.g. application will not work). Obviously, if it’s already happened, the likelihood is rather high, don’t you think?

Even today, there are many that firmly believe that if a team works to improve/introduce software quality, it will delay the schedule. The antithesis is a false economy . In my experience, effectively employing practices/techniques such as developer testing, creating a fully automated build, continuous integration (CI), and automated deployment speed up quality and delivery with teams. Of course, I used a trick (some may say ‘clever’) word in the previous sentence…”effectively”. For instance, if you try to do CI without a fully automated build, you will have problems. Or, try to write developer tests that rely on specific values in the database that aren’t aren’t updated/integrated into scripts, you’ll have problems. There’s no silver bullet here.

People will ask, so “If I do TDD, CI and automated builds, will this improve my speed and quality of delivery?” I must, in all good conscience, give you the consultant’s answer: “It depends!” If you’re incorrectly implementing these practices, it doesn’t matter what you call it, they’re not going to magically solve problems just because you gave it a name. Unfortunately, the practices themselves can be misappropriated as the culprit of the schedule delay or quality problems (e.g. I always get a chuckle out of the: “We stopped using CI because our builds kept failing”).

Fail fast is a good mantra to follow. Learn from your mistakes and improve. Reacting to the latest emergency is necessary and inevitable. However, teams should seek to always learn and improve to lessen these occurrences in the future. People may say “Well, that’s just obvious!” Then, I will leave you with one of my favorite blog posts from Kathy Sierra. There’s a difference between saying and doing .