Em 1975, Frederick P. Brooks escreveu o revolucionário The Mythical Man-Month. Quarenta anos depois, esta série de artigos pretende revisar as afirmações e os argumentos do autor. Quanto o ofício da Engenharia de Software evoluiu desde então?

Capítulo 2: The Mythical Man-Month

Neste capítulo, Brooks argumenta que o tempo (ou a falta dele) é um dos principais motivos de falha em projetos de software.

Ele também argumenta que o bom cozinheiro demora para fazer uma boa comida. É necessário aos gerentes a coragem para fazer o cliente esperar por um bom produto.

Outra falha apontada por Brooks, também relacionada ao tempo, é que programadores são sempre otimistas. Ele sempre espera que o código dele execute com sucesso, sem erros, mas este nunca é o caso. Assim, nossas estimativas sempre ocultam uma suposição inválida de que tudo vai correr bem, nada vai dar errado.

Ainda na linha do tempo, Brooks lança o argumento central do livro, ou seja, a refutação de que trabalhadores e horas são grandezas intercambiáveis. Segundo o autor, pode ser verdade que dobrando o número de pessoas para colher o trigo numa plantação fará com que o tempo para terminar o trabalho caia pela metade, mas o mesmo não se pode dizer do desenvolvimento de software. Existem tarefas dependentes, indivisíveis, há o fardo da comunicação entre as pessoas, a necessidade de treinar pessoas novas na equipe consumindo o tempo das que já estão no projeto e o trabalho de redistribuir os papéis da equipe.

Tudo isso deu origem ao que ficou conhecido como Lei de Brooks que, resumidamente, consiste na afirmação de que adicionar pessoas a um projeto atrasado, na verdade atrasa ainda mais o projeto.

Segundo o autor, o número máximo de pessoas em um projeto deve ser determinado de acordo com o número de tarefas que podem ser divididas de forma independente umas das outras.

Considerações

Mais uma vez, neste segundo capítulo, vemos a análise brilhante de Brooks sobre projetos de software permanecer totalmente consistente com a realidade mesmo com o passar dos anos. Em linhas gerais, todos os pontos são muito válidos ainda hoje.

É claro que muitos argumentaram e ainda argumentam sobre alguns pontos. Toda a regra tem sua exceção, mesmo a Lei de Brooks. Por exemplo, adicionar uma pessoa chave, experiente e comprometida, em um projeto atrasado pode até salvar o projeto. Mas esta é uma exceção e não a regra.

Além disso, há programadores que não parecem tão otimistas, pelo contrário, querem ganhar tempo e dão estimativas muito maiores. Mas, creio eu, mesmo estas na verdade são relativas a estimativas que eles fazem em suas mentes, as quais acabariam sendo otimistas de qualquer forma.

Pense num desenvolvedor preguiçoso que dá a estimativa de uma semana para um trabalho que ele secretamente acredita levar apenas um dia, na esperança de ter outros quatro dias de "tranquilidade". Em geral, esse programador vai procrastinar da segunda à quinta-feira e, quando tentar começar o trabalho real na sexta, vai perceber que é mais difícil do que parecia a princípio ou que ainda existem dependências não resolvidas. O resultado é que, mesmo tendo mais tempo do que o suficiente, ele ainda vai relatar ao chefe na outra segunda-feita que precisa de mais tempo. Esta é uma pequena ilustração de como qualquer estimativa, mesmo quando cinco vezes maior, pode ainda culminar em atraso.

Não é incrível como muito da sabedoria que alguns acham ter surgido no movimento agile já existe há muito mais tempo do que se imaginava? Talvez você seja um daqueles que desprezam a Engenharia de Software tradicional associando sua imagem com processos, burocracia ou teorias que não tem nada a ver com a prática. Porém, renegar o conhecimento de grandes autores significa repetir os mesmo erros novamente quando você ir um pouco além do desenvolvimento por tentativa e erro.

Espero que, mais uma vez, este capítulo lhe tenha dado um gosto especial pela leitura, assim como tenha sido útil em mostrar que ainda existe muito conhecimento importante dos tempos “antigos” da Engenharia de Software que nós precisamos resgatar e reter, ao invés de andar sempre na “última moda” sem conhecer as origens de um ofício ainda tão recente da humanidade.

Vejo você no próximo capítulo! 😀