Quality standards don't always mean fewer defects

Are low defect rates more important than quality standards? Project management expert David Christiansen discusses when standards shouldn't be enforced and how managers can understand the distinction between quality standards and quality software.

How should I deal with somebody who is a great software developer and produces software with a low number of defects, but repeatedly ignores quality standards?

I'm not sure the problem is the developer. If I were you, I would try to find out what this person is doing that your quality standards are not. It sounds like this person is producing fewer defects than those who don't ignore the quality standard.

Standards almost always have unintended consequences -- maybe he is aware of some that other developers don't think about.
That, to me, says more about the quality standard than the developer. Maybe it's not all it's cracked up to be. You must FIRST understand why his work product is good before you try to do anything about the compliance issue.

Next, find out why he ignores the standards. Maybe he knows something you do not about the relevance of those standards. Standards almost always have unintended consequences -- maybe he is aware of some that other developers don't think about and he has made a conscious decision that the consequences of following the standard are worse than the consequences of not following the standard, including your frustration with him.

Finally, you need to be able to articulate why not following the standards is a problem in a more substantial way than something akin to, "because it's our process." What are the real effects of him not complying? Do you fail audits? Do companies refuse to use your product as a result? Does it just get you in trouble? Or does it simply irritate you that one of your developers isn't interested in being a cog in the machine? Whatever the real cost of the failure to comply, you need to be able to describe it.

Software quality management:
A software quality crisis is brewing

Software quality best practices

Project management: How to compose a project team

I would consider leaving this developer alone. It sounds like he/she is a good resource. If you force this person to comply, and their work quality suffers as a result, or worse, they leave your organization, will you feel that the benefit from this change outweighs the cost? The best thing might be to just cover for this person as much as you can and reap the benefits of their productivity and quality.

Dig Deeper on Topics Archive