Estou fazendo 4-5x mais pontos de história do que a média, mas produzindo bugs na metade da taxa. Os gráficos dizem que é 2x mais bugs, como lidar com isso?

Portanto, é geralmente aceito que os programadores de primeira linha podem produzir uma ordem de magnitude com mais / melhor código do que seus pares mais comuns.

Também é geralmente aceito que a taxa de erros cometidos no código é relativamente constante para os programadores.

Em vez disso, tende a ser impactado pelos processos usados ​​ao escrever o código e depois que o código é escrito . (Pelo que entendi) Os seres humanos tendem a cometer erros a uma taxa constante - melhores programadores apenas percebem mais deles e são mais rápidos em corrigi-los.

• Observe que as duas afirmações acima vêm do Code Complete, de Steve McConnell - portanto, não se trata de perspectivas diferentes.

Então, eu comecei a ver isso recentemente no meu código. Posso calcular cerca de 4-5x a quantidade de código que muitos de meus colegas (medidos pelos pontos da história estimados pela equipe), com maior qualidade (com base nas métricas de desempenho e no número de alterações feitas após o check-in). Mas ainda cometo erros. Entre melhores testes de unidade, uma melhor compreensão do que o código está fazendo e um melhor olhar para os problemas ao fazer revisões de código, não estou produzindo 4-5x o número de bugs.

Mas ainda estou produzindo cerca de duas vezes mais erros encontrados pelo controle de qualidade que outros desenvolvedores da minha equipe. Como você pode imaginar, isso causa alguns problemas com pessoas não técnicas que fazem medições métricas (leia-se: meu chefe).

Tentei ressaltar que estou produzindo bugs na metade da taxa dos meus colegas (e consertar o dobro), mas é difícil vender quando há gráficos dizendo que produzo o dobro de bugs.

Então, como lidar com o fato de que o aumento da produtividade levará a um número maior de bugs?

Eu acho que você está misturando suas preocupações. E não há nada do seu lado que você precise mudar.

Produtividade é uma dica de quão rápido um projeto será concluído. Os gerentes de projeto e todo mundo gostam de saber quando o projeto será entregue. Maior ou mais rápida produtividade significa que o projeto será entregue mais cedo.

A taxa de erros não está ligada à produtividade, mas ao tamanho do projeto. Por exemplo, você pode ter Nerros por Ylinhas de código. Não há nada nessa métrica que diga (ou se importe!) A rapidez com que essas linhas de código são escritas.

Para juntar isso, se você tiver uma produtividade mais alta, sim, "verá" os bugs sendo escritos mais rapidamente. Mas você teria esse número de bugs de qualquer maneira, já que está relacionado ao tamanho do projeto.

De qualquer forma, maior produtividade significa que você terá mais tempo no final do projeto para procurar esses bugs ou o desenvolvedor será mais rápido em encontrar os bugs que eles criaram. ¹

Para abordar os aspectos mais pessoais da sua pergunta.

Se o seu chefe estiver olhando estritamente para o número de bugs que você produz, em oposição à taxa de bugs que você produz, uma sessão educacional é necessária. O número de bugs criados não faz sentido sem uma taxa de suporte.

Para levar esse exemplo ao extremo, diga ao seu chefe que quero dobrar seu salário. Por quê? Não criei bugs no seu projeto e, portanto, sou um programador muito superior ao seu. O que? Ele vai ter um problema que eu não produzi uma única linha de código para beneficiar seu projeto? Ah Agora, entendemos por que a taxa é importante.

Parece que sua equipe tem métricas para avaliar bugs por ponto da história. Se nada mais, é melhor do que ser medido pelo número bruto de bugs criados. Seus melhores desenvolvedores devem criar mais bugs porque estão escrevendo mais código. Peça ao seu chefe que jogue fora esse gráfico ou, pelo menos, jogue outra série por trás dele, mostrando quantos pontos da história (ou qualquer valor comercial que você medir) juntamente com o número de bugs. Esse gráfico contará uma história mais precisa.

¹ _{Esse comentário em particular atraiu muito mais atenção do que pretendia. Então, vamos ser um pouco pedantes (surpresa, eu sei) e redefinir nosso foco nesta questão.}

_{A raiz desta pergunta é sobre um gerente observando as coisas erradas. Eles estão analisando o total de erros brutos quando deveriam analisar a taxa de geração versus o número de tarefas concluídas. Não vamos ficar obcecados com a medição em relação a "linhas de código" ou pontos de história ou complexidade ou qualquer outra coisa. Essa não é a questão em questão e essas preocupações nos distraem da questão mais importante.}

_{Conforme disposto nos links do OP, você pode prever um certo número de bugs em um projeto apenas pelo tamanho do projeto. Sim, você pode reduzir esse número de bugs através de diferentes técnicas de desenvolvimento e teste. Novamente, esse não era o objetivo desta pergunta. Para entender essa pergunta, precisamos aceitar que, para um determinado tamanho de projeto e metodologia de desenvolvimento, veremos um determinado número de bugs quando o desenvolvimento estiver "completo".}

_{Então, finalmente, voltemos a este comentário que alguns completamente incompreendidos. Se você atribuir tarefas de tamanho comparável a dois desenvolvedores, o desenvolvedor com uma taxa de produtividade mais alta concluirá a tarefa antes do outro. O desenvolvedor mais produtivo terá, portanto, mais tempo disponível no final da janela de desenvolvimento. Esse "tempo extra" (em comparação com o outro desenvolvedor) pode ser usado para outras tarefas, como trabalhar nos defeitos que percorrerão através de um processo de desenvolvimento padrão.}

_{Temos que acreditar no OP de que eles são mais produtivos do que outros desenvolvedores. Nada dentro dessas alegações implica que o OP ou outros desenvolvedores mais produtivos estejam sendo negligentes em seu trabalho. Assinalando que haveria menos erros se eles passassem mais tempo no recurso ou sugerindo que a depuração não faz parte desse tempo de desenvolvimento, perde o que foi solicitado. Alguns desenvolvedores são mais rápidos que outros e produzem um trabalho comparável ou de melhor qualidade. Novamente, veja os links que o OP estabelece em sua pergunta.}

Passe um tempo extra limpando, polindo e testando seu código. Ainda haverá erros, mas haverá menos. Isso leva tempo. Sua taxa de saída de código diminuirá, mas sua saída de código sem erros aumentará e isso resultará em melhor produtividade. Porque os erros são caros.

Você pode manter seu código em uma ramificação ou ambiente de teste até que você o contorne e consiga mais erros? Erros em uma ramificação geralmente causam menos ondas do que erros no código de produção.

Mas não estou exatamente procurando suas afirmações levando à sua pergunta. E talvez seu chefe também não seja.

Eu não acho que todo codificador produz a mesma taxa de erros. Seu segundo link é realmente totalmente fora de tópico, pois compara diferentes idiomas, e não diferentes níveis de habilidade do codificador. O código completo menciona algumas medidas de amostra grande que estão analisando o processo e não a habilidade dos codificadores. E quando eles dizem que os codificadores de nível superior produzem mais / melhor código, parte disso significa que ele possui menos erros. Depende da aplicação. Então, sim, acho que é uma questão de perspectiva diferente.

No final, se o chefe quiser um código mais limpo, dê a ele um código mais limpo.

Vou me expor e ser o advogado do diabo. Isso não quer dizer que não simpatize com sua situação, mas, bem, minha simpatia não vai ajudá-lo. Então, permita-me acrescentar à perspectiva de Philip :

Seu chefe se preocupa com a qualidade do produto, em parte porque o nome e a reputação dele estão vinculados a ele. Parte da qualidade é a quantidade percebida de erros . Se você vender uma broca incrível que perfura quatro vezes mais rápido do que qualquer broca concorrente, mas também quebra duas vezes mais, você terá uma má reputação. Mesmo que seja discutível que a broca tenha um desempenho melhor, as pessoas se acostumam à velocidade, mas elas se lembram das falhas.

Em retrospectiva, a maioria dos bugs é obviamente evitável. Se você fosse um pouco mais cuidadoso, sentirá seu chefe, você poderá evitar esses problemas e qualquer limpeza necessária. Da perspectiva dele, isso é trivial e sensato, e qualquer discussão que você faça a respeito não funcionará e fará com que você pareça ruim.

Ele não pode medir sua produtividade superior. Você alega maior produtividade com base em uma métrica verificável. Então, como seus colegas se sentem sobre isso? Eles concordam, talvez de má vontade, que você é um programador mais produtivo ou que está sozinho na sua opinião? Você fará uma afirmação mais forte se tiver outras pessoas para apoiar suas afirmações.

Isso é por perspectiva. Agora, como você 'conserta' essa situação frustrante em que está?

Desacelere um pouco. Mencione explicitamente a quem distribuir tarefas que você tentará diminuir a taxa de erros (*), para que não fiquem surpresos com sua menor ingestão. De qualquer forma, diminuir a velocidade reduzirá o número de bugs atribuídos a você por falta de suprimento.

_{(*) Há uma diferença entre, por um lado, reconhecendo que não são bugs para o seu nome e que você vai tentar diminuir essa quantidade e, por outro lado, admitindo que você tem muitos bugs para o seu nome e deve tome uma atitude.}

Não tente convencer seu chefe, porque não vai funcionar. Novamente, isso não significa que você tenha que concordar com seu argumento; você pode apresentar um contraponto e manter sua opinião sem descartar as preocupações dele. Porque, se você argumentar e não puder provar satisfatoriamente sua produtividade superior (e mesmo se puder), correrá o risco de insultar seus colegas ou parecer desprezível. Você não quer ser esse cara .

Supondo que você produziria a mesma "quantidade" de código como seus colegas em 20% do tempo, você poderia gastar quatro vezes mais em realmente depurando o código e aperfeiçoá-lo, o que reduziria ainda mais a taxa de erros. Então você pode se chamar um bom programador.

A maior questão é por que você está codificando 5 vezes mais do que os outros, em vez de buscar qualidade. Isso é algo que seu ego dita ou seu chefe o força?

Além disso, você precisa considerar os custos para corrigir um bug. Quando você o encontra cedo, ainda pode estar "dentro" do código o suficiente para corrigi-lo rapidamente. Se ele aparecer apenas após mais um mês de desenvolvimento, poderá ser difícil encontrar ou até forçá-lo a alterar grandes partes do código já programado.

Você parece ter o conjunto de habilidades para produzir código e pode ser incrível se focar na qualidade, e não na velocidade. Tente um pouco, meu palpite é que você vai gostar.

O próximo problema é obter o reconhecimento (falar dinheiro) pelo seu melhor desempenho. Converse com seu chefe e pergunte a ele como proceder, é a empresa e o dinheiro dele, afinal, e se ele quiser que você produza menos bugs, ele também deve decidir de que maneira isso acontece.

Os desenvolvedores podem ser inteligentes, até geniais, com aptidão para entender e codificar solo, sem serem BOM desenvolvedores. Um bom desenvolvedor cria um trabalho de qualidade e melhora todo o projeto.

Não estou dizendo que este é você, mas um dos programadores mais frustrantes com quem trabalhei escreveu mais código do que qualquer um na equipe, e tínhamos boas pessoas na equipe. Nós rastreamos commits com um software de classificação, então era quase uma competição para algumas pessoas. Ele produziu faixas de código, deixando para trás documentação ZERO, florestas impenetráveis ​​e, na verdade, dificultou a compreensão de alguns dos meus códigos (eu posso fazer isso sozinho, muito obrigado!). Eventualmente, ele quase atrapalhou o projeto, porque ele se tornou um show de um homem. As pessoas não podiam segui-lo. Não estávamos em sincronia como equipe. Na verdade, reescrevemos alguns de seus recursos anos depois, apenas para recuperar a manutenção.

O que eu queria dele era diminuir a velocidade e gastar mais tempo: 1) Melhorando a qualidade da base de código 2) Comunicando-se com a equipe 3) Trabalhando em coisas que ajudavam os outros, além de ajudá-lo a terminar os recursos / histórias 4) Fixação insetos

Não concordo em medir a produtividade por linhas de código, mas é uma métrica chave. O seu contador de códigos inclui comentários? Nesse caso, existe uma maneira fácil de manter sua saída de linha enquanto reduz sua "taxa de erros"; simplesmente aumente a qualidade e a quantidade de comentários que você escreve. Os comentários raramente apresentam bugs (embora possam) e, em geral, não temos comentários de qualidade suficientes. Estou não tolerar code-inflação, mas o ato de comentar é como uma mini-revisão de código, ele força você pensa, refatorar e melhorar.

Tentar esclarecer a gerência não é uma tarefa fácil. Há um velho clichê: "Você vai acreditar em mim ou em seus olhos mentirosos?" O que preocupa seus chefes são as contagens de bugs. Nenhuma racionalização dirá que é aceitável. É mais do que o dobro de risco. Além disso, você não é o único afetado pela sua contagem de erros. O controle de qualidade tem o dobro do trabalho tentando identificar seus erros, portanto, o gerenciamento vai querer que você os reduza.

A melhor solução é reduzir o número de bugs que você produz , ponto final. A gerência não apenas será mais feliz, mas você também. Você não vai? Porque eu tenho certeza, tanto quanto você gosta ostentando você superar seus colegas de trabalho por um fator de quatro, você ama quer dizer que você fazê-lo fazer o mesmo número de, ou até menos, erros do que eles.

Como você declarou, "... a taxa de erros cometidos no código ... tende a ser afetada pelos processos usados ​​ao escrever o código e depois que o código é escrito". Se você quiser alterar a taxa na qual você produz bugs, precisará alterar os processos usados ​​para escrever o código.

Programadores usam métodos de produção para produzir código, assim como uma linha de montagem usa métodos para produzir algum objeto produzido em massa. Tudo bem, as práticas da indústria de software são mais parecidas com bugigangas de galhos encontrados na floresta. Porém, como estamos produzindo máquinas, devemos empregar o mesmo rigor e disciplina usados ​​nas máquinas de produção em massa de alta velocidade.

Isso inclui as mesmas técnicas usadas na produção em massa para reduzir a taxa de defeitos: análise da causa raiz para determinar por que os erros são cometidos e alterar o processo para que não sejam. Ou pelo menos você deve pegar antes do controle de qualidade.

1. Faça uma lista dos seus erros. Você provavelmente já recebeu uma graças ao pessoal do controle de qualidade. Possivelmente categorizado também. Tipo de erro, gravidade, o ponto em que o erro foi injetado no código, etc.

2. Escolha a maior categoria de bugs. Como seu volume é muito alto, você deve segmentar essa categoria primeiro. Outras categorias incluem as mais fáceis de encontrar e as mais fáceis de criar.

3. Para saber onde esses bugs são introduzidos no código, tente fazer alterações nessa fase (e anterior) que impeçam a ocorrência desses bugs e maneiras de facilitar a captura deles nessa fase.

4. Certifique-se de observar incidentes não relacionados à programação, pois eles podem fazer a diferença na qualidade do seu trabalho. Música de fundo, interrupções, refeições, trabalho por muito tempo sem interrupção, fome, etc.

O que você encontra pode levar você a ir mais devagar. Por outro lado, pode ajudá-lo a produzir ainda mais rápido, pois você terá menos necessidade de refazer o material que já colocou atrás de você. Como é, quatro vezes mais código não está perto de ser uma ordem de grandeza melhor do que seus colegas de trabalho; portanto, mudar seu processo é definitivamente o caminho a percorrer.

Mude seu objetivo de produzir o maior número de códigos para ajudar a empresa a avançar mais.

Como parece que você tem muitos colegas, além de um tempo extra disponível, o maior efeito que você pode ter sobre uma entrega mais rápida de recursos e correções de bugs é ajudar seus colegas.

Ajude seus colegas

• usando revisões de código para melhorar a qualidade e a educação do código.
• criando automação de processos para tornar seu trabalho mais rápido e suas vidas mais fáceis.
• escrevendo melhores testes com eles
• atacar código técnico para melhorar a base de código
• sendo o cara que está sempre disponível para ajudar os outros.
• ferramentas de escrita / aprimoramento que ajudam na produtividade do desenvolvedor
• defendendo a gerência para melhores ferramentas / equipamentos / condições de trabalho para seus colegas de trabalho, se você tiver mais influência.
• preparando e liderando sessões educacionais sobre como escrever um código melhor.
• praticando humildade

Então, como lidar com o fato de que o aumento da produtividade levará a um número maior de bugs?

Seu chefe é a única pessoa que pode responder a isso no seu caso. Fale com ele, aponte sua melhor proporção e deixe-o decidir. Se a decisão dele não faz sentido, é hora de procurar uma empresa com sua maneira de pensar.

Como profissional, você deve ser capaz de trabalhar com qualquer condição do cliente, apenas certifique-se de que ele entenda as consequências. Um bom gráfico de bugs / histórias pode ajudar seu chefe a entender quanto sua produtividade diminuirá se você dedicar algum tempo para produzir menos bugs.

Você também precisa considerar estes pontos:

• complexidade das histórias, por exemplo, invólucros getter / setter simples versus cálculos estatísticos ou programação em tempo real ou até estatística estatística em tempo real ...
• gravidade dos erros, são pequenos erros de digitação nos campos de texto ou resultados de cálculos incorretos, falhas no programa
• custo para corrigir os erros, se você o fizer agora, mais tarde ou se outra pessoa precisar entender seu código porque você saiu

A situação é que você trabalha quatro vezes mais rápido que o programador médio, mas comete o dobro de erros em um determinado período de tempo. Em relação à quantidade de trabalho que você faz, você na verdade comete metade dos erros que a "média".

Você pode tentar apontar sua baixa taxa de erros em relação ao trabalho ou até mesmo erros em relação ao produto concluído (que pode ser concluído em um quarto do tempo normal). A maioria dos chefes aceitará isso.

Existem alguns chefes que não o fazem porque trabalham com uma mentalidade de "tolerância" de erros por vez. Em seguida, você pode diminuir o ritmo do seu trabalho, fazendo o dobro da média em um determinado período de tempo e cometer os mesmos (ou menos) erros, porque você tem mais tempo para verificar o seu trabalho.

Se o seu chefe deseja que você melhore a qualidade do seu trabalho, melhore a qualidade do seu trabalho.

Você deve ter como objetivo zero bugs, não para produzir apenas o dobro do próximo melhor programador.

Você deve dizer ao seu chefe que as métricas que ele está usando são bastante falhas. Se você der uma olhada nas rotatividade dos guardas da NBA, verá que eles tendem a ter números mais altos do que os avançados. Mas isso é porque eles estão lidando mais com a bola. Se um guarda que não joga a partida joga 1/5 do que um guarda inicial e vira a bola 3 vezes em média .vs. um guarda inicial que vira a bola mais de 7 vezes por jogo - à primeira vista, pode parecer que o guarda inicial é pior. Mas, se você dividir o número de turnovers pelo número de minutos jogados, então claramente o guarda inicial terá números muito melhores com base nos minutos jogados.

Da mesma forma, você tem números muito melhores se o número de bugs for dividido pelo número de pontos da história concluídos. Então, é isso que eu proporia ao seu gerente. Altere a métrica para ser o número de bugs dividido pelos pontos da história concluídos ou, pelo menos, adicione uma nova métrica se o número total de bugs por desenvolvedor for necessário. Porém, como alguns pontos da história são muito mais difíceis e complexos do que outros, pode e haverá muita variação, e isso também deve ser levado em consideração pelo gerente.

O que eu acho que você não deve fazer é desacelerar.

Medir o valor adicionado

Argumente que o que realmente conta é o valor que você adiciona. Em seguida, introduza uma medição aproximada (manual) disso:

• Estime o valor da funcionalidade que você produz
• Subtrair seu salário
• Subtraia o custo estimado dos seus erros (pelo menos o custo para corrigi-los)
• Subtraia o custo estimado de todas as outras Dívidas Técnicas que você produzir

O restante é o seu valor agregado. Da mesma forma para todos os outros.

Essas estimativas são difíceis, mas mesmo as mais grosseiras podem fazer sentido. E o mero processo de discutir essas estimativas é útil para a equipe e o projeto.

Os principais programadores tendem a escrever códigos muito regulares que são fáceis de depurar e entender; eles utilizam as ferramentas disponíveis (análise estática, erros do compilador, código de depuração) ao máximo. Além disso, os principais programadores já aprenderam o valor do teste de unidade por meio de sua própria experiência.

Portanto, embora a quantidade inicial de problemas por linha seja a mesma, os problemas são eliminados mais rapidamente.