Sean, I must compliment you for the nice article. Given that the attrition rate is so high(at least in India) and the growing discontentment among software employees, its high time that the companies start focusing on their hiring procedures.

Though I mostly agree with you what you have said, I would like to add one important point.

One of the reasons for the problem that exists with the current hiring procedure(in most of the companies) is the presence of too much human intervention.

The managers, the consultants, the HR personnel, the interviewers etc., all of them interacting among themselves using mail/phone and as a result some of the conversations are lost forever.

I strongly feel that for effective hiring there has to be a dedicated software which would facilitate the activities of all the stakeholders involved.

Hi Amit, I agree that communication is an important challenge for the hiring team. Please say more about the software you envision and specifically how it would help.

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.

Ian,
In partial answer is this article which showed up on DZone - http://gojko.net/2010/07/05/how-to-do-agile-when-we-only-have-50-crap-developers/

I don't know of any exceptions to the policy. While I was there one guy got one letter. The other bug we had was determined to have been from a requirement so was not ITs fault.

I think one factor that made the policy work was that developers knew coming in that two bugs was the limit so bad developers weren't interested in taking the job.

We never had to fix bugs so we worked on new features. As part of development, we created a test plan up front that SMEs and QA approved. The policy was never in my thoughts.

When working in an environment that accepts bugs, I find that many managers would prefer a buggy solution today rather than a good solution tomorrow. I guess it is the broken window problem. Once there is one, a second is acceptable. So how does a good developer stand up to a shoddy manager? Maybe you empower the developer to say that **someone** will be fired if buggy code goes to QA.

The ideal hiring software would be browser based workflow driven software in which, for each recruitment, the managers would create a workflow consisting of steps/tasks, which are aligned to their companies recruitment policy.
So every stakeholders from the manager to the HR to the external consultant agencies, to the interview panel to the candidate etc are part of this workflow and each of them provide their feedback through the software.

This would ensure that each stakeholders have a consistent/same view of information, say job description, which is so often distored from the time it starts from hiring manager till it reaches the candidate.

Then there are so many other benefits which the software brings:
1) Consitent hiring practice. Since each hiring process is available for viewing, the management can periodically validate the process.
2) Which consultant is providing the high performers?
Difficult to get the answer of this and many such questions without software
3) A la carte training schedules for the new recruits based on thier gaps identified during the interview.

There are so many advantages.
I am not sure whether we already have such software but I strongly feel the need of one.

Hi Amit, I often think about how task-specific software could improve hiring. I haven’t evaluated what’s out there but the few packages I’ve seen HR teams try to bring in-house fall short. They tend to be inflexible and lock the company into wrong-minded or ill-fitting hiring practices.

I think you got many of the requirements right. I think a solution must be flexible both for differences from company to company, and for differences among organizations within a company.

An alternative to hiring-specific software could be Jira, corporate scheduling and email. This isn’t ideal but Jira does a decent job at workflow; scheduling has to go through the corporate system or it becomes a mess; and both of these tend to integrate well with email as a notification/general communication device.

This falls short in a few areas. First, custom work must be done to gather the hiring metrics. It is unclear to me – not being a Jira guru – how to do this. The second is on the sourcing side. There’s no automation to assist in entering candidates into the workflow either internally via HR, or externally via recruiters. This could probably be done with a bit of glue code.

Since I err on the side of people over process (and software), I don’t feel passionate about the need for a package to ‘solve’ the hiring ‘problem.’

This strikes me as a truly horrible policy.

You are hiring people to be paranoid and "not to make any mistakes". They will spend all their time to do so. Since bugs seem to be allocated to an individual, where's the teamwork?

For most applications, (something like security software is arguably an exception!) you should be hiring people to be creative and to work as a team to succeed.

> This strikes me as a truly horrible policy.
>
> You are hiring people to be paranoid and "not to make any
> mistakes". They will spend all their time to do so.
> Since bugs seem to be allocated to an individual, where's
> s the teamwork?

It's lazy management. Instead of devising a system that prevents bugs from making it into production you simply take a page from Stalin's playbook. It's purely reactive and irrational.

I've heard of a similar approach being used in manufacturing an engineering in China where anyone caught making a mistake loses a month's pay (that approach would be illegal in the US.) The result was not a reduction in mistakes but more mistakes making it to later stages of production because people will put a lot of effort into hiding any errors. This is far more costly than if the error were addressed early on.

I've seen such things happen under less directly hostile management practices. In one previous employer, a multi-million dollar undertaking was found to not comply with pertinent laws. Instead of delaying the project to fix the issues, the project was 'completed' such that it would incur daily maintenance costs but would not produce any value. This allowed 'success' to be declared despite being the worst possible path out of the situation.

I have to ask those who protest so much, how many bugs do you guys put in production in a year? The policy protected me from working on bad, buggy code. I like working for people with high expectations.

What's your definition of a bug?

If it is something like "changing the color on page X doesn't refresh page Y if the FooBar dialog is open or if they are using the Windows Classic look and feel", then the answer is dozens, and, IMO, that's acceptable.

If the definition is "changing the color on page X crashes the app and loses data" then the answer is maybe 1 a year. And each one is fixed ASAP.

In my experience, both are considered "bugs". But with different rating, e.g. one is rated "critical", and one is "minor".

I've found over the years that bugs in production can occur because of differences between...

1. How the customer understands their system interacts with the outside world.

2. How we understand their system interacts with the outside world, from their specification.

3. How the system actually interacts with the outside world.

The three are not always completely identical.

> I have to ask those who protest so much, how many bugs do
> you guys put in production in a year? The policy
> protected me from working on bad, buggy code. I like
> working for people with high expectations.

The only way I can see the "2 bugs and you are out" system working is if there are really (really-really) well written specifications. The vast majority of bugs I've ever created were the result of vague or confusing requirements or because of poorly documented or undocumented 3rd party 'features'.

The worst bug I ever created occurred when my direct manager insisted that I manually merge my tested code with a contractor's work without giving me extra time to retest the code. Technically, yes, it was my error that caused the issue. But if a manager can't take a step back and see whether he or she could change something or allow the developer to change something to prevent the error from happening again, then he or she is not worth his or her salt.

There's a really interesting study that was done on Israeli fighter pilot trainees and trainers. The trainees were complaining that the trainers were berating them too harshly. When asked, the trainers said that it made the trainees fly better. A study was done and it was found that after being berated, the trainees almost always were better on their next flight. When commended, they did worse the next flight. They also found that touching them on the shoulder with a small stick had the same effect (I can't remember what the control actually was.) The reality was that their performance constantly fluctuated and when they did poorly (and were berated) they were likely to do better next time no matter what and vice-versa for the good performance. It's also been shown that people are far more motivated by rewards than punishments. For these reasons, I think the management approach you are recommending is malarkey.

James, do you have a reference to that study? I would be interested in reading it, but I'm having no luck finding it on The Google.

> James, do you have a reference to that study? I would be
> interested in reading it, but I'm having no luck finding
> it on The Google.

I got this from Peter Scholtes' "The Leader's Handbook" ISBN 0-07-058028-6.

The part about poking them with a stick is similar to what is is discussed in the book but was not part of the study (my apologies.) The study is only noted in the book as: Kahneman and Tverski, 1973, McKean, 1985.

> I got this from Peter Scholtes' "The Leader's Handbook" ISBN 0-07-058028-6.

Thanks - that looks like a good book; I might pick it up.