The Blame Game by Bruce Nielson
I want to discuss the need for blame on software projects. “Ug! The blame game! I hate that!” I hear you groan.
But it's an all too familiar game for all of us. We all know that software (or all human endeavors actually) end with what we call “the blame game” where we all point figures at each other and claim the failure was someone else's fault. We say we are mad when this happens, yet we participate in said game with uncanny gusto.
I think it's a mistake to overlook the human value of “the blame game.” Frustrating though it is, the end result of the blame game is usually that blame is redistributed around to the point where it's impossible to blame anyone, because everyone (or no one) was at fault. And I'd argue that this end result is generally the accurate one – there really was no one person at fault more so than just about everyone else.
In fact, most of the time, the “fault” is the “process,” not a person. (There is that dirty word “process” again.) Yes, there are many exceptions, but my experience is that most people (granted, not all) really do care about their projects. They want to be successful and they want to make their company successful. If there was a failure, it's generally because there was no recourse but the one taken.
An Example – Just Cut Testing!
Think about this familiar scenario: A software developer is faced with unreasonably mandated due date from the highest echelons of a large company.
Do they:
a) Have a nice chat with everyone up the food chain (possibly including the chairman of the board, the stockholders, or the competing company that forced the situation) and change the date to be more realistic, or
b) Quit their job now, since they’ve already failed, or
c) Make qualified statements about how “they can make it if…” knowing full well “if” will never happen.
For those that insist that they’d never choose option c, but would instead negotiate a better schedule, please, for the sake of argument, assume you tried that a thousand times and failed. So you now have to decide to either quit or go forward. You always have the option to quit later, of course.
I don’t know about you, but I’m not an idiot. I’d choose c over b. In fact, I’d dare say there is no choice here in the first place. C was the only correct answer.
In other words, my best bet is to take a stab at it.
I’d quickly come up with some written “requirements” (Heck, I’ll at least then be able to explain what requirements changed during the course of the project that way) but I’d have no qualms about reducing safety margins on other tasks, like say testing. (This is a painfully familiar story, right?)
Given this hypothetical circumstance, I’d have to be stupid to not use this approach.
Who’s to Blame for All These Defects?
When inevitably this leads to defects – perhaps even critical ones – can we truly say it's the developers fault? Or is it the testers fault for not having caught the defect? Or is it the project manager's for not planning enough time?
Or, here's a thought, maybe it's the Chairman of the Board’s fault for creating a culture where a developer finds himself in this position in the first place?
No wait! Maybe it’s the stockholder’s fault for demanding more than was reasonable.
You tell me, because it seems to me that you can't really pin the blame on anyone really. Granted, the Chairman of the Board (who probably didn't even know about the project) probably has more blame to shoulder than the developer who caused the problem. But can we really say it’s his/her fault?
So when things get ugly and the blame starts to fly, just repeat to yourself this little rule:
The blame game is a healthy way of redistributing blame until no one is found to be at fault.
Then, without guilt, play the blame game. Since you know it's a necessary ritual to moving on, you can choose to not be nasty about it. Defend yourself, but make it clear it's not “all your fault” either.
For example, let's say you are a developer. Go ahead and point out that you weren't given much test time, so it made sense to code and test quickly to make the schedule. Go ahead and point out that even the tester missed the problem. Go ahead and point out that if the company really wanted to see defect-less software, they'd take more time to get the software “just right” before a release. The end result is that you just blamed everyone else (including yourself) and helped appropriately redistribute the blame so that no one was really at fault.
And that's how it (generally) should be.