Parece que faria mais mal do que bem. Ignorando por um momento se é justo para um gerente fazer isso, vamos ver a logística ...
Problema 1: Todos os bugs são criados iguais?
O Desenvolvedor 1 introduz um bug: Apaga todos os dados do cliente e os amaldiçoa neles.
O Developer 2 introduz dois bugs: Os rótulos de formulário não são alinhados à esquerda e o recurso de calendário é desativado em 1 segundo se um evento for criado com dois anos bissextos.
Então, claramente, o desenvolvedor 2 merece mais sofrimento de seu gerente porque eles têm o dobro da taxa de erros. Claro que não, então você vem com um sistema de classificação de erros para que os desenvolvedores com bugs triviais não sejam tão afetados. Mas espere, deve o sistema fatorar em um modificador para um desenvolvedor que está claramente cometendo o mesmo erro trivial repetidamente e desperdiçando o tempo do testador, porque eles nunca aprendem com seus erros? Talvez, hmmm. Isso é complicado.
Problema 2: O que conta como um bug?
Gerenciador - Este relatório deveria incluir um total em execução, isso é um erro para você!
Desenvolvedor - Isso não estava nos requisitos, isso não é um bug.
Problema 3: Como você agrupa bugs?
Desenvolvedor - "[Nome do gerente], os testadores arquivaram 10 bugs contra mim porque as velocidades estavam incorretas 10 telas diferentes, mas tudo isso estava relacionado a um único bug na função getVelocity Nós discutimos por 3 horas sobre isso, mas eles não se moverão Nós gostaríamos de uma reunião com você para decidir quantos erros deveriam ser arquivados Ah, e a propósito, não há como chegarmos ao prazo final do código amanhã. "
Problema 4: Mais SLOC provavelmente significa mais bugs
Developer 1 fica na sua bunda o dia todo, mas consegue escrever 3 linhas de código livres de bugs entre argumentos no Reddit sobre a lei de imigração do Arizona.
O desenvolvedor 2 trabalha duro o dia todo e produz uma inteligência artificial totalmente funcional que não mata John Connor na primeira chance. "
Então, obviamente, você quer penalizar o desenvolvedor que faz mais progresso e / ou assume mais riscos inovando, certo?
Resumo
Provavelmente, existem soluções viáveis para várias delas, mas como gerente de uma equipe de programação tentando cumprir um prazo, você realmente quer que todos gastem tempo discutindo o que conta como um bug, o que conta como um bug discreto, a importância de um bug, etc? Nenhuma dessas coisas avança seu projeto e isso será um veneno para as equipes que serão forçadas a competir em questões que não tenham impacto significativo no software que está sendo criado. Sem mencionar o que ela faz com a cultura de seus funcionários para concentrar tanto esforço em encontrar maneiras de garantir que os erros de todos os funcionários sejam meticulosamente registrados para que possam ser jogados de volta em sua cara mais tarde.
Depois, há a questão do impacto adverso. Isso é conversa de RH, é melhor você ter uma boa documentação antes de começar a penalizar os funcionários, especialmente financeiramente. E se algum deles for uma classe protegida (minorias, veteranos, mulheres, deficientes, etc.) é melhor ter certeza de que qualquer sistema que você tenha criado não discrimina um deles com base em membros dessa classe (ou que um juiz pode ser convencido como tal), mesmo que seja apenas um efeito colateral involuntário do plano.
Por fim, você não está criando incentivos para criar menos bugs, o que é difícil, mas sim negociar os bugs minimizando sua importância ou culpando-os por outra pessoa.
Versão curta Não.