Alex and Joe,

I agree with both your comments to my last post.

Joe blames the dev…

“- No bug report- [dev] corrected it on their own

Obviously devs catch defects in their code (logic errors, missed specs, inefficiencies). If devs find and resolve defects in previously released code, should a bug be logged? On one hand, if the dev corrects it before anyone else catches it, why should the dev have to tell anyone? If a tree falls in the forest and nobody is around, does it make a sound? On the other hand, we can’t assume an unnoticed defect in the field, means said defect’s resolution will also be unnoticed. Thus, IMO it’s best for devs to let the team know about all changes. Typical ways to do this:

  • Dev logs bug

  • Dev tells tester to log bug

  • Dev logs a work item representing work they did (e.g., refactored code for FeatureA). The work item should be visible to the team. The dev gets credit for their wonderful coding, and the tester gets the tap on the shoulder to attempt some testing.

Alex blames the tester…

That test should have failed a long time ago.

In this case, the feature did not match its spec. You're damn right, the tester should have caught this! The tester should thank their dev for doing the testers job. (Unfortunately, if the tester relied on the spec, we would be right back where we started.)

So a third member must also take the blame; the spec author (e.g., Business Analyst), who did not capture the true business need of the feature. However, we can’t put all the blame on them. “The requirements sucked!” …this is a tired argument, one that I decided never to waste my time with. Anyone who disagrees probably has not attempted to write requirements.

The next time you feel compelled to point the finger at a teammate, don’t. Responsibilities blur across the software development trades and the whole team can share success or failure.

(sorry, this post is a little dull. I’ll try for something juicier next week)


  1. Anonymous said...

    I hate playing the blame game... especially during crunch time. At that point, whose fault it actually is matters very little. What matters is what can be done to resolve the problem.

  2. Eric Jacobson said...

    True that!

    Bad apples emerge on their own. So do heros.

  3. Anonymous said...

    One of the first thoughts that occurred to me was that it is possible that the tester and spec author KNEW the user's expectation, and the spec was never updated due to a myriad of reasons. This happens a lot at my company, and can be manageable at first, but eventually the documentation needs to get updated otherwise someone who wasn't part of the "nod and wink" will write up another bug or possibly in this place, just "fix" it.

  4. Tarik Sheth said...

    Well, I feel blame game is for week individuals. as a whole team every one is responsible for everything happened in the project.
    Person should be able to take the initiative to resolve the problem.

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.