Cozinhar bem leva tempo. Se fazemos você esperar é para servi-lo melhor e deixá-lo satisfeito

Este princípio fundamental da culinária de qualidade se aplica perfeitamente ao desenvolvimento de software. A urgência do cliente, embora compreensível, não pode, e nem deve, reger o tempo de conclusão real de um projeto. Apressar um chef pode resultar em um omelete cru ou queimado. Apressar um time de desenvolvimento tem consequências análogas, e geralmente mais custosas.

Mítico Homem Mês (O capítulo que da nome ao livro)

Por que tantos projetos de software falham mais por falta de tempo no calendário do que por todas as outras causas combinadas? A raiz do problema reside em uma métrica de estimativa falha: o Homem-Mês.

A Falácia do Homem-Mês

O erro central está em tratar o esforço de software como tarefas de colheita de algodão ou debulha de trigo. Em tarefas de força bruta, homens e meses são, de fato, intercambiáveis: o custo pode variar com o número de pessoas, mas o progresso linearmente sim. Se dez pessoas conseguem debulhar o trigo em um mês, espera-se que vinte o façam em meio mês.

Isso é categoricamente falso na programação de sistemas.

Em tarefas complexas que precisam ser divididas, mas que exigem comunicação entre as subtarefas, adicionar mais pessoas a um projeto não o acelera; pelo contrário, o atrasa.

O esforço de intercomunicação é o fator mais grave. Se cada porção da tarefa deve ser coordenada com as demais, o esforço aumenta exponencialmente. O número de canais de comunicação aumenta com a fórmula n(n−1)/2.

  • Três trabalhadores exigem 3 vezes mais comunicação entre pares do que dois.
  • Quatro trabalhadores exigem 6 vezes mais comunicação do que dois.

Como a construção de software é, por natureza, um trabalho sistemático e interconectado, o esforço de comunicação rapidamente domina qualquer diminuição no tempo de tarefas individuais. A adição de mais homens, paradoxalmente, aumenta, e não diminui, o tempo no cronograma.

Como um software atrasa um ano? Um dia de cada vez.

A Equipe Cirúrgica

Harlan Mills apresenta uma solução para equipes de programação, ao invés de um grupo se organizar como um grupo de matança de porcos, o ideal seria se organizar como uma equipe cirúrgica. Ou seja, ao invés de cada membro sair esfaqueando o problema, apenas um faz os cortes e os demais dão a ele todo o suporte que aumenta sua eficácia e produtividade.

O cirurgião

Mills o chama de programador chefe. Ele define pessoalmente tudo sobre o sistema, arquiteta o programa, codifica, testa e escreve documentação. Ele precisa ter muito talento, dez anos de experiência e considerável conhecimento de sistemas.

O copiloto

O alterego do cirurgião, capaz de executar qualquer parte do trabalho, embora seja menos experiente. Sua função principal é partilhar o projeto como um pensador, crítico e avaliador. Ele conhece a fundo todo o código do projeto. Seu papel não se limita apenas a um conselheiro. Ele também pode codificar, mas o responsável ainda é o cirurgião.

O administrador

Alguém para lidar com pessoal, dinheiro e as máquinas. O cirurgião é o chefe e deve ter a última palavra, mas não deve gastar muito tempo com isso

O editor

O cirurgião gera a documentação, o editor pega os rascunhos do cirurgião e os melhora, formata e adiciona referências bibliográficas

Dois secretários

O administrador e o editor precisarão de cada um, um secretário

O escrituário da programação

Responsável pela manutenção de todos os registros técnicos da equipe em uma biblioteca de programação e produto

O testador

O cirurgião precisará de um banco de testes apropriado para testar partes de seu trabalho à medida que escreve, assim com para testar o trabalho completo.

Como funciona

Eles não trabalham como piloto e copiloto, dividindo as responsabilidades, tarefas e decisões. O cirurgião decide tudo e o restante do pessoal apenas auxilia.

O Efeito do Segundo Sistema

O segundo sistema que um arquiteto constrói tende a ser o mais perigoso. Tenta ser o oposto do primeiro: ele vai ser hiperprojetado e tentará incluir todas as funcionalidades que foram deixadas de lado no primeiro projeto. A tentação de “fazer tudo certo desta vez” leva ao excesso de complexidade e atrasos.

Não existe bala de prata

Muitos buscam a próxima grande tecnologia ou técnica de gestão que irá, por si só, multiplicar a produtividade. Fred Brooks nos lembra:

Não há um único desenvolvimento, seja em tecnologia ou em técnica de gestão, que, por si só, prometa sequer uma ordem de grandeza de melhoria dentro de uma década, seja em produtividade, confiabilidade ou simplicidade.

A parte mais difícil da construção de software é o projeto conceitual (a especificação, o design e o teste da ideia), não a codificação em si (a representação e a verificação da fidelidade).

A maestria em software requer tempo, foco, clareza e organização estrutural, não atalhos ou aumento indiscriminado de pessoal.