“Um bom programador pode ser 10 vezes mais produtivo que um medíocre” [fechado]

Eu tinha lido uma entrevista com um grande programador (não está em inglês) e ele disse que "um grande programador pode ser 10 vezes melhor do que um medíocre", justificando o porquê de bons programadores serem muito bem pagos e por que empresas de programação oferecem muitas facilidades para seus funcionários. A idéia era que há uma demanda muito grande por bons programadores, por causa do motivo acima e é por isso que as empresas pagam muito para trazê-los.

Você concorda com esta afirmação? Você conhece algum fato objetivo que possa apoiá-lo?

Edit: A questão não tem nada a ver com experiência; se você fala de um grande programador com 1 ano de experiência, ele deve ser 10 vezes mais produtivo do que um programador medíocre com 1 ano de experiência. Concordo que, a partir de certos anos de experiência, as coisas começam a se dissipar, mas esse não é o objetivo da pergunta.

Uma visão geral e análise bastante detalhadas da pesquisa sobre diferenças de produtividade é fornecida em dois artigos escritos por Steve McConnell :

• Variações de produtividade entre desenvolvedores de software e equipes: a origem do "10x"

• Origens de 10X - Qual a validade da pesquisa subjacente?

O primeiro artigo ( Variações de produtividade ... ) declara:

... O estudo original que encontrou grandes variações na produtividade individual da programação foi conduzido no final dos anos 1960 por Sackman, Erikson e Grant (1968). Eles estudaram programadores profissionais com uma média de 7 anos de experiência e descobriram que a proporção do tempo inicial de codificação entre os melhores e os piores programadores era de cerca de 20 para 1; a proporção de tempos de depuração acima de 25 para 1; do tamanho do programa 5 para 1; e a velocidade de execução do programa é de 10 para 1. Eles não encontraram relação entre a quantidade de experiência de um programador e a qualidade ou produtividade do código.

Um exame detalhado das descobertas de Sackman, Erickson e Grant mostra algumas falhas em sua metodologia ... No entanto, mesmo depois de contabilizar as falhas, seus dados ainda mostram uma diferença de mais de 10 vezes entre os melhores programadores e os piores.

Nos anos que se seguiram ao estudo original, a descoberta geral de que "existem diferenças de ordem de magnitude entre programadores" foi confirmada por muitos outros estudos de programadores profissionais (Curtis 1981, Mills 1983, DeMarco e Lister 1985, Curtis et al. 1986 (Card 1987, Boehm e Papaccio 1988, Valett e McGarry 1989, Boehm et al 2000) ...

^{Este artigo também tem uma observação interessante:}

^{Esse grau de variação não é exclusivo do software. Um estudo de Norm Augustine constatou que, em uma variedade de profissões - redação, futebol, invenção, trabalho policial e outras ocupações - os 20% das pessoas produziam cerca de 50% da produção, sejam eles touchdowns, patentes , casos resolvidos ou software (Augustine 1979).}

O segundo artigo ( ... Qual a validade da pesquisa subjacente? ) Foi escrito principalmente para tratar da revisão crítica do primeiro por Laurent Bossavit :

• crítica original em francês: Folklore or fait scientifique, comment les différencier
• Tradução para o inglês: fato e folclore na engenharia de software .

No segundo artigo, na seção Um mergulho mais profundo na pesquisa “10x”, McConnell verifica novamente mais detalhadamente as referências usadas no primeiro artigo e conclui:

... Ao revisar essas citações mais uma vez ao escrever este artigo, concluí novamente que elas apóiam a conclusão geral de que existem diferenças de produtividade em 10x entre os programadores. Os estudos envolveram coletivamente centenas de programadores profissionais em diversas atividades de programação.

... o corpo de pesquisa que apóia a afirmação de 10x é tão sólido quanto qualquer pesquisa realizada em engenharia de software. Os estudos que apóiam a alegação de 10x não estão singularmente sujeitos à limitação metodológica descrita na Figura 1, porque estão estudando a própria variabilidade individual (ou seja, apenas o lado esquerdo da figura). O Bossavit não cita nem mesmo um estudo - defeituoso ou não - que contraria a afirmação de 10x, e eu também não vi nenhum desses estudos. O fato de nenhum estudo ter produzido descobertas que contradizem a afirmação de 10x fornece ainda mais confiança na afirmação de 10x. Quando considero o número de estudos realizados, em conjunto, considero a pesquisa não apenas sugestiva, mas conclusiva - o que é raro na pesquisa de engenharia de software.

Por uma questão de integridade, a lista de referências usadas nas variações de produtividade ... também é citada abaixo:

Referências

Agostinho, NR 1979. "Leis de Agostinho e principais programas de desenvolvimento de sistemas". Revisão de gerenciamento de sistemas de defesa: 50-76.

Boehm, Barry W. e Philip N. Papaccio. 1988. "Entendendo e controlando os custos de software". Transações IEEE em Engenharia de Software SE-14, no. 10 (outubro): 1462-77.

Boehm, Barry, et al., 2000. Software Cost Estimation with Cocomo II, Boston, Mass .: Addison Wesley, 2000.

Boehm, Barry W., TE Gray e T. Seewaldt. 1984. "Prototipagem versus especificação: uma experiência de multiprojeto". Transações IEEE em Engenharia de Software SE-10, no. 3 (maio): 290-303. Também em Jones 1986b.

Card, David N. 1987. "Um programa de avaliação de tecnologia de software". Tecnologia da informação e software 29, no. 6 (julho / agosto): 291-300.

Curtis, Bill. 1981. "Substanciando a variabilidade do programador". Anais do IEEE 69, no. 7: 846.

Curtis, Bill, et al. 1986. "Psicologia de Software: A Necessidade de um Programa Interdisciplinar". Anais do IEEE 74, no. 8: 1092-1106.

DeMarco, Tom e Timothy Lister. 1985. "Desempenho do programador e os efeitos do local de trabalho". Anais da 8ª Conferência Internacional de Engenharia de Software. Washington, DC: IEEE Computer Society Press, 268-72.

DeMarco, Tom e Timothy Lister, 1999. Peopleware: Projetos Produtivos e Equipes, 2ª Ed. Nova York: Dorset House, 1999.

Mills, Harlan D. 1983. Produtividade de Software. Boston, Massachusetts: Little, Brown.

Sackman, H., WJ Erikson e EE Grant. 1968. "Estudos experimentais exploratórios comparando o desempenho da programação online e offline". Comunicações da ACM 11, no. 1 (janeiro): 3-11.

Valett, J. e FE McGarry. 1989. "Um resumo das experiências de medição de software no laboratório de engenharia de software". Revista de Sistemas e Software 9, no. 2 (fevereiro): 137-48.

Weinberg, Gerald M. e Edward L. Schulman. 1974. "Objetivos e desempenho em programação de computadores". Fatores humanos 16, no. 1 (fevereiro): 70-77.

Um programador genuinamente terrível pode ter uma produtividade abaixo de zero (os erros que eles introduzem levam mais tempo para serem corrigidos do que levaria apenas para fazer todo o trabalho deles).

E um programador genuinamente excelente pode fazer coisas que os programadores pobres e medianos simplesmente nunca conseguiriam, independentemente de quanto tempo você lhes desse.

Portanto, por esses motivos, é difícil falar em "10x como produtivo" ou "100x como produtivo".

O que deve ser lembrado, porém, é que a maioria dos empregadores de programadores não precisa executar tarefas difíceis que os programadores comuns não conseguem gerenciar. A maior parte do código que está sendo escrito é de sites, aplicativos de linha de negócios, aplicativos de intranet etc., muitos dos quais realmente não são tão difíceis. O programador produtivo nesse ambiente é aquele que melhor entende e implementa as necessidades dos usuários, não quem pode escrever o código mais inteligente.

De fato, a maioria dos empregadores de programadores estaria melhor com um bom programador do que com um bom programa, porque o grande simplesmente fica entediado e vai embora. Preciso encontrar uma boa correspondência entre programadores e trabalhos.

Fatos e falácias dos estados de engenharia de software (Fato 2, disponível na visualização amazon):

Os melhores programadores são 28 vezes melhores que os piores, de acordo com a pesquisa "diferenças individuais". Dado que o salário deles nunca é proporcional, eles são os maiores negócios no campo do software.

(procure a lista de fontes para pesquisa)

Obviamente, se você comparar a produtividade de um não programador (ou um programa muito ruim) com o bom (em termos de experiência e conhecimento), a diferença pode ser infinitamente grande ( n/0 == infinitypara qualquer positivo n), mas não é justo nem comparação sensata.

Seu salário pode depender de vários fatores (em ordem aleatória):

• Tecnologias utilizadas
• País / estado em que trabalha
• Riqueza da empresa
• Tipo de negócio da empresa
• Número de desenvolvedores na empresa
• Quanto tempo você trabalha na empresa
• A política do escritório

juntamente com o seu pessoal ...

• produtividade
• conhecimento e experiência
• envolvimento nos negócios da empresa (para startups)
• habilidades de negociação
• atratividade e habilidades sexuais, lol (bem, a inteligência é sexy)

Minha resposta é "sim, mas tenha cuidado ao usar essa métrica".

Um programador que, digamos, está funcionando da melhor maneira possível, é aquele que cria funcionalidade e causa menos erros que precisam ser corrigidos do que seu irmão de desempenho inferior. Não acho difícil acreditar que essas pessoas possam ter uma produtividade 10 vezes maior do que as outras, principalmente quando você considera que uma única escolha boa ou ruim feita em uma hora pode ter 10 horas de impacto e os programadores fazem muitas dessas escolhas. maioria dos dias.

Mas...

Você tem cuidado ao medir isso. Realmente não confio na maioria das medições de produtividade, pois já vi casos intermináveis ​​em que quase todas as métricas conhecidas não consideram algo que considero vital para a produtividade da equipe. Então, eu geralmente odeio números tão difíceis por "produtividade". Aqui estão alguns exemplos:

• Linhas de código (LOC) - uma métrica geralmente odiada, uma vez que um programador impensado pode gerar muitas linhas de código horríveis, detalhadas, ineficientes e difíceis de depurar, enquanto um bom programador cria algumas linhas de código elegantes, fáceis de corrigir e raramente quebradas em mais tempo, mas no geral são uma escolha melhor.
• Bugs gerados e / ou tempo para consertar - todos geram alguns bugs, e geralmente os bugs mais caros são gerados por uma série de decisões ruins para as quais o gerador do problema é apenas o último no efeito dominó. Além disso, seus grandes depuradores nem sempre são seus grandes designers - você precisa de ambos.
• Por quase todas as métricas, existem ótimos desenvolvedores que são tão dolorosos para uma equipe, que 1 desenvolvedor "super produtivo" afastará 10 basicamente bons desenvolvedores e eu raramente vejo alguém que possa fazer tudo bem, então precisamos mais de 1 pessoa no projeto.
• Não há como explicar com facilidade essas pessoas maravilhosas que vêem os problemas surgirem antes de serem sérios e os enfrentam, principalmente quando o problema é uma lacuna em um processo - CM defeituoso, construção ineficiente, lacuna nos testes, falha de segurança - essas muitas vezes parecem uma grande perda de tempo até você perceber que eles o salvam de um desastre - não há como medir isso.
• Além disso, existem pessoas que considero necessárias em uma equipe de um determinado tamanho que eu chamaria de "construtores de coesão" - raramente o máximo absoluto de produtividade, geralmente ainda estão nos 20% superiores e fazem o trabalho inestimável de ajudar a acelerar pessoas novas, conectando os pontos e certificando-se de que as perguntas certas sejam feitas e que as pessoas certas sejam mantidas informadas, elas escrevem (sem serem solicitadas!) a parte principal da documentação a que todos se referem porque não é apenas o documento certo, mas é montado da maneira certa. Se você quer que 10 pessoas trabalhem com eficiência máxima, você absolutamente precisa de uma dessas pessoas e não conseguirá isso se colocar 10 super desenvolvedores em uma sala.

Muitos sistemas de medição tentaram levar esses fatores em consideração, mas ainda tenho que ver que há um que leva todos esses problemas em consideração. Por isso, nunca estou muito impressionado com fatores como "um bom desenvolvedor é 10 vezes mais produtivo do que um medíocre ", porque tenho que me perguntar se a métrica é realmente responsável por todo o trabalho necessário para um produto contínuo bem-sucedido ou uma equipe próspera e bem-sucedida.

Então, minha grande ressalva é: o que você fará com essa métrica? Usarei algo assim para estar ciente de que as ferramentas e o talento certos podem causar uma grande diferença na maneira como o trabalho é realizado, mas se você tentar otimizar para uma equipe em que cada indivíduo produz 10 vezes a produção "típica", você está pronto para um caso de frustração. Melhor é encontrar uma maneira de fazer com que sua equipe faça 2 a 3 vezes o que eles estavam fazendo antes, trabalhando melhor juntos.

Em seu livro Os Duendes da Engenharia de Software , Laurent Bossavit descreve a pesquisa da reivindicação de produtividade de 10x. Ele descobriu que não há números sólidos por trás disso - a alegação passou de especulação para "fato estabelecido" por um jogo telefônico de alegações sucessivamente mais concretas na citação. A postagem do blog que compreende o capítulo sobre a afirmação 10x e inclui as citações e citações incorretas relevantes, é fato e folclore na engenharia de software .

O que ele descobriu é algo assim: alguém em 1968 fez um estudo comparando pessoas resolvendo um problema específico de depuração e descobriu que alguns deles o faziam 10 vezes mais rápido que outros. A partir disso, podemos concluir que algumas pessoas são 10 vezes melhores na solução desse problema , ou podemos concluir que algumas pessoas tiveram sorte ou uma grande variedade de coisas diferentes. Algumas pessoas optaram por citar isso como (estas são todas paráfrases) "um estudo (Sackman et al, 1968) descobriu que alguns programadores trabalham 10 vezes mais rápido que outros". Em seguida, tornou-se "estudos demonstraram que bons programadores são 10x melhores que a média" e, finalmente, "é de conhecimento geral que a produtividade do programador varia em 10x entre os indivíduos". Então alguém coleta todas essas citações, citando incorretamente uma fonte original para dizer "muitos pesquisadores acreditam ...".

Obviamente, não seria um jogo por telefone se apenas a veracidade da afirmação mudasse: o multiplicador passa para 11 e além .

" O programador produtivo nesse ambiente é aquele que melhor entende e implementa as necessidades dos usuários, não aquele que pode escrever o código mais inteligente. " (Da resposta Carson63000 )

Esse ponto-chave, juntamente com bethlakshmipontos de faz um ponto enorme. Um grande desenvolvedor pode ser ótimo em sua fatia da realidade, mas se desfaz assim que o mundo muda. Ser capaz de acompanhar as necessidades da empresa é muito mais importante do que qualquer outra coisa. No final do dia, a menos que seu negócio seja tecnologia, ele não se importa com tecnologia; eles precisam de soluções. Portanto, ser bom com padrões de design não significa agachamento para usuários finais que precisam apenas de um despejo de dados para exibir em uma página da web. Vi desenvolvedores medíocres garantirem um emprego, atendendo às empresas que os apoiam, enquanto grandes desenvolvedores ficam entediados e vão embora em busca de um desafio sem fim. Dependendo da sua organização e projeto (s), é possível alimentar esses desenvolvedores famintos por desafios, mas provavelmente haverá um momento no qual você simplesmente não não precisa dessa quantidade de poder de processamento. Esses desenvolvedores não gostam de ficar ociosos como um processador. Eles vão desligar e reiniciar em outro lugar.

Por fim, direi que não há problema em saber quem são seus "principais" artistas, mas uma "equipe" de desenvolvimento ainda é uma equipe. Para reiterar bethlakshmi, "o que você fará com essa métrica?"Se você precisar de uma equipe que se comporte como uma equipe, eu não focaria em métricas como essas. Eu perceberia que mesmo o menor jogador ainda é uma parte importante da equipe. Mesmo com 60% menos da produtividade da sua chave jogador, esse jogador pode estar dando ao seu time o que ele precisa. Descubra o que é e tente multiplicá-lo. Não queime seu principal jogador, assumindo que ele deve liderar o time, encontre maneiras de multiplicar sua saída também, contaminando os outros jogadores com essa grandeza. Isso requer um pouco de criatividade, e não apenas números. No final, você pode aprender que o que faz um bom programador não é nem mesmo esse programador; podem ser seus colegas, suas oportunidades no local de trabalho ou pode até ser você.