As organizações devem penalizar os desenvolvedores pela quantidade de relatórios de defeitos arquivados em relação ao código em que eles trabalharam? [duplicado]

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.

Os programadores são notórios por otimizar o que os gerentes começam a recompensar. Se você recompensar o LOC, então você terá muito espaço em branco para preencher as linhas da métrica de código. Se você tentar punir por contagem de bugs, você começará a entrar em guerras onde os desenvolvedores afirmam que X não é seu bug (o bug está no compilador ou API ou apenas em outro lugar) - e o bug registrado contra eles está errado.

O último lugar em que trabalhei tinha um desenvolvedor "encarregado" de um produto. Enquanto o devedor "responsável" nunca mudou ao longo dos anos, outros trabalhariam no projeto quando a carga sazonal o tornava necessário. Ninguém apontou os dedos e disse "você escreveu esse bug!" Em vez disso, o objetivo era reduzir os erros nos produtos.

Os lugares que eu trabalhei que tinham penalidades para os bugs também tiveram um turno muito alto. O apontamento de dedos contribuiu para um ambiente hostil que levou à partida dos desenvolvedores.

Os desenvolvedores devem se responsabilizar pela qualidade do código que produzem, e devem esperar que o gerente faça o mesmo. Mas isso não significa que algum desenvolvedor deva obter um demérito toda vez que um bug for relatado. Nenhum gerente em sã consciência diria:

Well, Johnson, you checked in 500 lines of code last week, and so far 241 bug reports have been traced to that code.

É muito trabalhoso descobrir quem é o culpado por cada pequeno defeito, e o número de relatórios de erros nem sempre lhe diz muito sobre a qualidade do código. Mas um bom gerente deve notar problemas e encontrar maneiras de corrigi-los. Ele ou ela pode dizer:

Johnson, that was one stinker of a checkin last week -- we've been getting bug reports at three times the normal rate. We need to get that fixed ASAP, so I've asked 'Eagle-Eye' Ferguson to go over the code with you. I'm sure the two of you will figure it out, and ol' Eagle-Eye might show you a few tricks along the way.

Todo desenvolvedor deve esperar que o gerente perceba seu desempenho, incluindo a qualidade geral de seu código. Os desenvolvedores também devem esperar que seus colegas percebam - está tudo bem no repositório, afinal. Então, se você é aquele cara com a alta contagem de bugs, não tenha vergonha de pedir ajuda. O resto da equipe provavelmente já sabe onde você está, e se você fizer um esforço conjunto para melhorar a equipe (e o gerente) também notará isso.

Então, sim , você deve ser responsável pelo código que escreve, mas não , a organização não deve ter uma política de penalizar desenvolvedores individuais por defeitos específicos , ou por exceder um certo número de relatórios de defeitos. Isso só vai encorajar as pessoas a encontrar maneiras de evitar a culpa, como apontar os dedos ou ser tão cuidadoso que a produtividade caia. Isso não ajuda o esforço de desenvolvimento se as pessoas tiverem medo de aceitar a responsabilidade pelo que escrevem. BTW, também não ajuda a revogar e recompensar correções de bugs específicas . ; -)

Não, eles não deveriam. Isso não é trabalho manual e nenhum cria erros intencionalmente. Como podemos esperar produtividade de um programador triste e horrorizado? As coisas deveriam estar frias ao redor dele. Em última análise, ninguém se beneficia de penalizar.  

Eu digo que esta é uma má idéia que fará pouco além de criar um ambiente de trabalho hostil.

Eu chegaria a ponto de dizer que QUALQUER REFORÇO NEGATIVO como um motivador para o desempenho no trabalho criará uma força de trabalho infeliz e alta rotatividade. Mesmo os bons desenvolvedores se sentirão estressados por escorregar.

O reforço negativo é mesmo humilhante para crianças e cães, por que você trataria um profissional dessa maneira?

Em vez disso, use reforços positivos para NÚMEROS DE BAIXO DEFEITO e tente ajudar ativamente os membros da sua equipe que estão com dificuldades. Se não funcionar com alguém a longo prazo, então deixe-os ir.

Eu vou resistir a tendência aqui, sair em um membro, e dar um ressonante SIM! , mas com uma certa qualificação: apenas para desenvolvedores que são pelo menos um desvio padrão pior do que o seu pares.

Deixe-me explicar um pouco, porque há alguns problemas carregados aqui. A primeira é a palavra "pares". Certamente não é certo comparar o trabalho de um veterano de 10 anos com o de um novo contratado recém-saído da faculdade. O novato tem menos experiência, mas o profissional recebe tarefas mais difíceis.

O próximo é o desvio padrão. Os programadores historicamente, por um lado, resistem a qualquer tentativa de mensuração quantitativa de seu trabalho com as alegações de jogos das métricas e, por outro, praticam a arte de encontrar diariamente maneiras de quantificar o incompreensível através de métricas de software e cotação sobre como os programadores de rockstar são X vezes mais produtivo do que a média. Há alguma verdade óbvia em ambos os lados.

Acredito que as melhores métricas de uso, até mesmo simplistas, como "linhas de código", são para identificar os diferenciais. Você define um limite de um desvio padrão ou dois de distância da norma, de tal forma que os programadores individuais não conseguirão sair do grupo. Não procure pelo programador superior ou inferior. O ponto principal aqui é que na maioria das vezes, ninguém é identificado e então não há nada para o jogo. Mas de vez em quando isso te ajudará a achar aquela pedra preciosa de um programador, ou te dirá quem é seu verdadeiro sub-performer. E então você sabe o que faz? Nada . Pelo menos no começo. Em vez disso, pense nisso como uma inteligência não confirmada. Use as informações para observar a pessoa e procure confirmá-la em outro lugar.

Se você tem um programador que está checando bugs com uma frequência maior do que seus colegas, primeiro encontre algo para corroborar seu desempenho geral e depois converse com ele. E a primeira vez, provavelmente deveria ser apenas uma conversa.

Minha opinião é não, porque se uma organização penaliza os desenvolvedores pela quantidade de bugs arquivados contra eles, o desenvolvedor pode ser menos produtivo para evitar as penalidades, supondo que sejam substanciais. Também pode haver conflito sobre quais bugs seriam arquivados em relação a um desenvolvedor, pois pode haver uma pessoa de controle de qualidade tendo uma visão liberal do que constitui um bug que é outro fator aqui. Enquanto alguém poderia tentar equilibrar as penalidades, eu ficaria curioso para ver como isso é feito na realidade.

Meu ex-colega de trabalho me contou a história de um local onde essa prática foi realmente aplicada: os desenvolvedores foram penalizados por cada bug encontrado em seu código, e o controle de qualidade foi recompensado por cada bug descoberto. O resultado foi que os desenvolvedores simplesmente pararam de desenvolver novos códigos porque essa era a única maneira de se protegerem das penalidades.

Desenvolvedores não são naturalmente preguiçosos ou ignorantes sobre o que é melhor. Na minha opinião, seria mais produtivo dar aos desenvolvedores uma linha do tempo mais precisa e melhores especificações antes do início do projeto.

Não. Parece tentar tratar um sintoma, não o problema da raiz. Em vez de se concentrar em quantos bugs existem em um pedaço de código e quem os apresentou, por que não se concentrar em desenvolver um sistema que ajude a eliminar bugs em primeiro lugar?

Ferramentas como Testes Unitários, Testes de Integração, Desenvolvimento Dirigido por Testes, Análise de Código Estático, Revisões de Projeto e Revisões de Código geralmente conseguem um número razoável de bugs antes de entrarem na base de código. A Integração Contínua também ajuda a identificar os problemas precocemente, em vez de depois.

BTW, o seguimento lógico da pergunta do OP: Se eu herdar um pedaço de código cheio de bugs, devo ser penalizado por todos os bugs restantes se eu corrigir um deles? Pela proposição original, desde que trabalhei no código, agora sou responsável pelos bugs.

Definitivamente não.

É como rebaixar os médicos porque alguns dos pacientes morrem, sem considerar a gravidade da doença / lesão.

Existem alguns projetos em que os defeitos são inevitáveis. Se você tem patrocinadores de projetos com necessidades conflitantes, requisitos do usuário que entram em conflito com as diretrizes de segurança, mas com alterações de última hora, haverá defeitos não importando a qualidade do seu código.

Há também o problema perene (pelo menos na maioria das grandes organizações) da infraestrutura que está mudando ao seu redor. Você codifica para V1.25 do banco de dados na V3.8 do sistema operacional, mas outro departamento faz upgrades para V2.0 e V4.0 antes de você entrar em operação. (Ou downgrade, em um caso nós codificamos para V5.0 J2EE apenas para ter o upgrade cancelado e tivemos que remover o defactor até V4.0 dias antes do lançamento - havia muitos defeitos.).

Por último, temos os usuários pragmáticos que criam defeitos em vez de solicitações de mudança, pois a carga burocrática é significativamente menor.

Qual é a motivação para penalizar os desenvolvedores por suas taxas de defeitos?

O objetivo é tentar medir a qualidade do código que está sendo escrito pelo desenvolvedor.

O problema é que quality é um pouco amorfo: é realmente difícil de medir. Na verdade, você não pode medir diretamente, você tem que tentar e aproximá-lo, medindo outras coisas.

Além disso, escolher um único KPI - como # defeitos - resulta em jogos do sistema. Se você sugerir penalizar cada desenvolvedor $ 10 por defeito, quanto tempo você acha que seria antes de um dos desenvolvedores fazer um acordo com um testador ... Eu vou te pagar $ 5 por cada defeito que você me disser que não Não fique logado.

Permita que eles repassem todos os erros relacionados ao código, encaminhem as reclamações do departamento de testes e eles já devem saber que menos bugs são melhores para eles.

E quando tudo dá certo, e nenhum relatório de bugs está chegando, um aplauso nas costas como recompensa e algumas palavras gentis devem fazer o resto.

Embora eu não concorde com a premissa ...

Isso só poderia ser viável se você recompensasse o programador que também assume características tecnicamente mais desafiadoras - "maior risco, maior recompensa". Caso contrário, por que um programador jamais aceitaria um trabalho desafiador nesse ambiente, uma vez que qualquer desafio técnico é um passivo (não uma oportunidade de recompensa).

Eu concordo que isso criaria um ambiente muito hostil também. Na minha experiência, uma quantidade significativa de defeitos é devido à ambigüidade do requisito ou apenas à falta de um requisito. Então, eu acho que isso também poderia levar a que esses defeitos fossem explicitamente atribuídos ao analista de negócios, engenheiro de sistemas ou patrocinador do projeto e eles deveriam estar sujeitos a essa mesma penalidade - o que não seria uma coisa ruim.

Eu diria que contá-los é um erro. Não há como você conseguir algo assim até um número. No entanto, se o código de um determinado desenvolvedor parece ter mais problemas do que códigos similares escritos por outros, e este é um padrão consistente, então eu diria que o desenvolvedor provavelmente não é tão bom, todas as outras coisas sendo iguais. É um fato para ser colocado na mistura.

De qualquer forma, estou neste negócio há décadas, e não posso dizer que já vi um programador que tivesse uma taxa de bugs anormalmente alta ou incomumente baixa. Já vi programadores que eram mais rápidos ou mais lentos, programadores que conseguiam trabalhos ou que enfrentavam problemas. Eu vi programadores que naturalmente escrevem muito fácil de entender código, código muito rápido ou código muito confuso. Mas eu nunca vi um programador com uma taxa de erros alta ou baixa atípica. Talvez eu não tenha prestado muita atenção.

Não me oponho a essa idéia - mas SOMENTE se houver consenso sobre os defeitos: um grupo designado de técnicos superiores que os rege. Usuários, BAs e gerentes geralmente não estão qualificados para decidir o que é um defeito de código - e é sempre perigoso colocar algo assim sob o controle de um (ou qualquer) indivíduo.

Mas eu não acho que seja realmente necessário - quando um desenvolvedor está constantemente escrevendo código ruim, se seus seniors e colegas estão fazendo seu trabalho, não será um segredo por muito tempo e o desenvolvedor sofrerá as consequências com um sistema formal de 'deméritos'.