Como todos nós aprendemos na aula de história no ensino médio, a Revolução Industrial deu origem a processos de fabricação acionados por máquinas que aumentaram muito a produção, reduziram os custos dos bens manufaturados e elevaram o padrão de vida de todos. Ela até mudou a forma como a sociedade era estruturada, pois expandiu massivamente a classe média e trouxe para casa a ideia de que a tecnologia poderia melhorar nossas vidas.
Uma Mudança na Forma de Trabalhar
Uma das mudanças que a Revolução Industrial trouxe foi a forma como trabalhávamos. A noção de economias de escala levou a fábricas cada vez maiores. Conforme as coisas avançavam, percebemos que a produtividade poderia ser medida facilmente. Trabalhadores parafusando as tampas em tubos de pasta de dente podiam ser prontamente observados e tampas fixadas com sucesso contadas. Especialistas em eficiência como Frank Gilbreth, do famoso Cheaper by the Dozen, encontraram maneiras de fazer as fábricas funcionarem de forma mais eficiente.
Pode-se argumentar que a Revolução Industrial terminou no dia em que o computador ENIAC foi entregue ao Exército dos EUA, sinalizando o início da Era Digital. Desde aquele dia, a indústria de desenvolvimento de software tem lutado para gerenciar o desenvolvimento de software de forma eficaz.
Lutar a Última Guerra
A raiz dessa luta vem de "lutar a última guerra". Uma preocupação bem conhecida nas forças armadas é gastar muito tempo pensando em guerras anteriores ao se preparar para as futuras, confiando em tecnologias e estratégias ultrapassadas que foram eficazes no passado, mas acabam não sendo tão eficazes no futuro. (Pense na Pickett's Charge à luz do desenvolvimento do rifle de alta precisão.) A indústria de desenvolvimento de software não é menos culpada disso.
Medindo a Produtividade
Essa tendência se comprova de várias maneiras. Todos nós já vimos o tropo do apito da fábrica e as pessoas se movendo pela entrada da fábrica "batendo ponto", seguidas por gerentes vagando pelos andares certificando-se de que as tampas estão sendo colocadas eficientemente nas latas de creme de barbear. Isso fazia um certo sentido.
Os trabalhadores eram medidos por sua produção, e a produção era facilmente medida. Trabalhadores em pé na linha de montagem para um turno padrão se tornaram um bom indicador de sucesso. Mais pés gastando mais tempo plantados ao longo da linha de montagem significavam mais produção.
Infelizmente, traduzimos isso em traseiros em cadeiras no negócio de desenvolvimento de software. Isso se manifestou mais recentemente por empresas forçando as pessoas a voltarem ao escritório em tempo integral. Assim como os trabalhadores no chão de fábrica, esperava-se que os desenvolvedores de software estivessem em suas mesas martelando em seus teclados produzindo... o quê exatamente? Código? Recursos?
O sucesso de uma fábrica de chaves de fenda é medido pelo número de chaves de fenda que ela pode produzir, dada uma certa quantidade de entrada. Então, parecia razoável medir o que os desenvolvedores de software produzem. Todos nós sabemos o desastre que medir Linhas de Código acabou sendo. Mas o que, exatamente, um desenvolvedor de software produz? Temos dificuldade em medir a produtividade individual do desenvolvedor , em grande parte porque não conseguimos responder bem a essa pergunta.
O Controle de Tempo
Talvez a pior herança da era industrial seja a noção de controle de tempo. Os gerentes sentem uma forte necessidade de medir algo, e o "tempo gasto em uma tarefa" se torna um objeto brilhante e poderoso que é difícil de resistir. Assim, as equipes geralmente precisam controlar a quantidade de tempo que leva para corrigir cada bug ou concluir tarefas individuais. Esses tempos são então comparados entre os desenvolvedores para fornecer alguma medida de produtividade e um meio de determinar o sucesso. Um tempo médio menor de correção de bugs é bom, certo? Ou não?
A Pior Métrica de Todas
O controle de tempo de desenvolvedores de software é — em uma palavra — horrível. Não há dois bugs iguais, e desenvolvedores inexperientes podem ser capazes de rapidamente produzir correções para muitos bugs fáceis, enquanto desenvolvedores mais experientes, que geralmente podem receber os problemas mais desafiadores, levam mais tempo. Ou talvez o desenvolvedor júnior seja designado para um bug que ele não consegue lidar? Pior, o controle de tempo encoraja os desenvolvedores a tentarem manipular o sistema. Quando estão preocupados com quanto tempo uma tarefa pode levar, eles podem evitar aquelas que podem levar mais tempo do que a "estimativa" e todo tipo de atividades "não produtivas".
Aprendendo com o Passado
Não temos que admitir que não há como determinar quanto tempo uma unidade de trabalho de software específica deve ou vai levar? Ter que contabilizar cada minuto do dia apenas cria incentivos ruins para cortar custos. Também pode fazer com que um desenvolvedor inteligente e capaz se sinta ansioso ou preocupado por levar "muito tempo" para resolver problemas desafiadores que deveriam ser uma "mudança fácil de uma linha".
Sabemos quanto tempo deve levar para aplicar rótulos em potes de maionese. Mas ninguém pode prever com grande certeza quanto tempo levará para consertar um bug não trivial ou implementar um novo recurso. Forçar as pessoas a controlar o tempo em tarefas de duração indeterminada tem muitas desvantagens e, bem, basicamente nenhuma vantagem.
Produtos digitais não são produtos físicos. Software é um produto completamente diferente de tudo o que já foi visto antes. Pensar que criar software pode ser gerenciado e executado usando as mesmas técnicas aprendidas durante a Revolução Industrial é fundamentalmente falho. Felizmente, mais e mais organizações não estão mais se preparando para "lutar a última guerra" e perceberam que o que funcionou na linha de montagem de uma fábrica de automóveis não funciona em uma loja de desenvolvimento de software.
