21–30 of 145 posts
A root cause analysis should ask "five whys" as to why this happened. Tight schedules, bad specs, improper training? Blaiming everything on the individual who checked the code in is not going to be very accurate, and probably very bad for morale.
Earlier quoted context omitted.
[deleted]
In interviews, remember never to mention anything negative about your current job no matter how you are treated, because that makes you seem like a negative nancy! Who knows, maybe you will even complain if you are treated poorly at your next job?
If you have an idiot coder that has been there forever and is hard to get rid of then this field would come up in their evaluation. Needless to say it may get overlooked on other peoples evaluation. It may be used as a way to manage some muppet out the company for wasting everyone's time.
But I don't know the full story, the boss may be a control freak and an idiot himself but he may be actually trying to improve working conditions, he just chose the wrong terminology for the field.
[deleted]
Now, others already advised you to quit the job — but that's obviously not so easy. But be careful, and if you can, find another outlet for creativity, because this can seriously damage both what you can offer to other companies, and how much you'll be able to enjoy any job.
Good luck.
As it is, bug trackers are good at collecting information and letting you create a process that is as convoluted as you'd like to track the work towards coming up with and releasing a fix, but leave much desired when it comes to trying to reduce your overall defect rate.
That said, trying to pin the blame on someone is the absolute worst way to accomplish any of this, and virtually guarantees that any "root cause" information you try to gather is going to be completely useless.