|
Re: Hiring as a Core Competence
|
Posted: Jul 5, 2010 11:45 AM
|
|
Greg, I can see that for certain industry areas, what you describe *might* make sense. If the software being produced is one where a bug has a strong likelihood of, say, costing lives or ruining the company, then its important to raise "bug free" to a job requirement. For many (I would argue, most) software projects, however, this isn't the case. Moreover, it's often the case that an early delivery of software with a few small bugs gives much higher business value than a late delivery of bug free code.
As I read your description, I took away that after a second defect, a developer was fired. This raises two questions. The first is, was *any* bug counted as a defect for these purposes, or only more serious ones? Firing someone for failing to close two transactions is one thing; firing them for failure to close two html tags is another.
The second question is, was a person's tenure and contribution taken into consideration when executing this policy? A developer making two mistakes in a month might be a serious liability to a team; one who has only made two mistakes in five years could be worth keeping (unless they achieved this through inaction).
I ask these two questions because as I read the policy you described, it seemed extreme in its inflexibility; I'm wondering if in practice there were compensating factors that made it more workable.
|
|