Grande produtividade do programador - respondendo por 10.000 vezes a diferença? [fechadas]

Um grande operador de torno comanda várias vezes o salário de um operador de torno médio, mas um grande gravador de código de software vale 10.000 vezes o preço de um gravador de software comum. - Bill Gates

Digamos que haja um "ótimo" engenheiro de software e um "médio" engenheiro de software na mesma equipe. Como você pode explicar que um engenheiro é 10.000 vezes mais produtivo? Não consigo entender isso, já que os dois assumem sua parte de recursos, bugs e investigações, e entregam consistentemente com qualidade. Minha descrição justificaria que eles estivessem acima da "média"? "ótimo"?

O ponto da citação não é que um seja 10K vezes mais produtivo, é que um é 10K vezes o valor do outro. O software tem a condição única de que um projeto ou implementação defeituoso possa ficar inativo por anos (uma peça usinada incorretamente geralmente "simplesmente não funciona" e não entra em campo), bem como no ciclo de vida do produto até que um dia ele levanta a cabeça em uma situação intratável.

Todos devem estar familiarizados com o custo exponencial de corrigir um defeito à medida que ele passa do design, para a implementação, para o teste, para a produção e para a manutenção.

Quando você considera a possível responsabilidade e a reputação corporativa, é fácil concluir que o desenvolvedor que sabia o suficiente para evitar o problema vale 10.000 vezes o que implementou uma solução ruim por ignorância ou ingenuidade.

Editar (primavera de 2014): "Heartbleed"

O nadador olímpico médio pode nadar cerca de 4 km por hora à distância.

A pessoa média (quem sabe nadar) pode nadar cerca de 2,4 quilômetros por hora a uma distância.

Isso significa que o nadador olímpico médio pode nadar no Canal da Mancha em cerca de 8 horas.

Seria lógico então que o nadador olímico é 60% mais rápido que a média e que o nadador médio levaria cerca de 13 horas para completar a corrida ...

Exceto que, se eu, um nadador comum, tentasse nadar no Canal da Mancha, a única maneira de atravessar é na praia uma semana depois.

Muitos aspectos da programação são como nadar no canal inglês. É afundar ou nadar. Eu nem sei se 10.000 vezes melhor é realmente uma maneira exata de descrever a distinção entre software concluído que funciona e software incompleto que não funciona.

Digamos que haja um "ótimo" engenheiro de software e um "médio" engenheiro de software na mesma equipe. Como você pode explicar que um engenheiro é 10.000 vezes mais produtivo? Não consigo entender isso, já que os dois assumem sua parte de recursos, bugs e investigações, e entregam consistentemente com qualidade. Minha descrição justificaria que eles estivessem acima da "média"? "ótimo"?

São muitas "sugestões" para um engenheiro de software "médio". Na realidade, o grande engenheiro de software resolve problemas em horas que o engenheiro médio nunca resolverá corretamente. O grande engenheiro de software resolve problemas comuns em um terço do tempo, com um quinto do código e um décimo do número de bugs. O código do grande engenheiro de software é executado em O (n) enquanto o código médio do engenheiro de software é executado em O (n ^ 3). O grande engenheiro de software pode adaptar sua solução enquanto você espera, enquanto o engenheiro de software médio reclama das alterações tardias nas especificações e diz que levará semanas para atender aos novos requisitos agora. Todas essas são diferenças reais que vi quando um grande engenheiro refaz o trabalho do engenheiro comum.

Vou tentar resolver isso em termos das diferenças:

Um grande engenheiro fará o seguinte melhor que o médio:

• Design - produza designs que precisarão de menos modificações e serão mais flexíveis. Isso se traduz em economia ao longo da vida útil do software.
• Recursos - estes serão implementados em jejum e serão implementações mais limpas.
• Bugs - serão encontrados mais rapidamente, serão bem corrigidos e não apresentarão menos bugs futuros.
• Investigações - serão concluídas mais rapidamente com melhores resoluções e resultados.

Tomados em conjunto, estes seriam salvar os lotes da empresa de dinheiro em tempo de desenvolvimento e fazer os lotes da empresa de dinheiro em oportunidades extras.

Um grande programador muitas vezes não apenas "assume sua parte de recursos, bugs e investigações" para ganhar um salário. Às vezes, eles saem e iniciam sua própria empresa, ou ingressam em uma startup, ou iniciam um novo projeto de skunkworks, ou, nos velhos tempos, talvez, ingressaram em um laboratório de pesquisa e desenvolvimento de renome nacional e inovam em algum produto que ninguém acha que precisava. , ou era possível pensar em software antes da percepção, habilidade e suor desse grande programador.

Grande parte desse "valor" do programador é sobre recompensa proporcional pelo risco. O programador pode até ter sido demitido por pensar em produtos de software malucos, em vez de receber 2X mais ou menos.

O que acontece com uma ocasional inicialização de software: tornar-se público por milhões / bilhões ou ser adquirido pelo Google ou Facebook, et.al. por quantias semelhantes, raramente acontece com operadores de torno (embora pelo menos um dos fundadores bem-sucedidos da empresa de tecnologia do Vale do Silício tenha um torno em sua oficina).

Existem algumas soluções que apenas os melhores programadores serão capazes de resolver. Jogar milhares de medíocres não funcionará. Também é mais difícil coordenar seus esforços, mesmo que eles possam combinar coletivamente as partes de seu conhecimento.

Responder a perguntas sobre SO não é diferente. Existem muitos problemas em que, dentre um grupo de desenvolvedores comuns, é possível encontrar a resposta. Esses sites provavelmente coordenam esforços muito melhor do que a maioria das equipes de desenvolvimento, o que é triste.

Eu acho que há alguma evidência empírica que apóia a citação de Gates. Lembro-me de ler (embora não me lembre da fonte) que, nos pools de digitação, a diferença na saída (facilmente mensurável para um pool de digitação) entre aqueles no percentil 5 e aqueles no percentil 95% era algo como 3 a 1. Mas depois que o software de processamento de texto ficou disponível, a proporção subiu para algo entre 10 ou 20 para 1, porque aqueles que podiam usar os recursos avançados do software ganharam ainda mais vantagens relativas.

Presumivelmente, para o desenvolvimento de software, a proporção seria ainda maior, pois há ainda mais liberdade para tirar proveito de todos os tipos de ferramentas, técnicas, etc. É mais difícil medir as diferenças, mas a maioria das tentativas ocorre com pelo menos 10 para 1 e presumivelmente isso está subestimando a diferença, porque está apenas medindo o que é fácil de medir.

Em algo como digitar ou operar um torno, as pessoas no top 1% provavelmente estão muito perto de atingir os limites fisiológicos do que é possível. No caso da programação, eles claramente não são (a proporção de quanto tempo leva para escrever o código versus quanto tempo leva para digitar o código é enorme), portanto, deve haver espaço para muito mais variações.