O Mítico Homem-Mês: Ensaios Sobre Engenharia de Software

Resumo

Publicado em 1975. Eu ainda vejo os mesmos problemas no trabalho. Fred Brooks escreve sobre gerenciamento de projetos, comunicação em equipes e complexidade de sistemas, não só código.

A obra me rendeu bastante reflexão. Insights que, surpreendentemente, ainda fazem sentido mesmo tanto tempo depois. Abaixo, alguns aprendizados que anotei enquanto lia, na ordem em que aparecem no livro.

Introdução

Li pela primeira vez em outubro de 2024 (definitivamente não a última). Se tivesse lido no começo da carreira, duvido que teria aproveitado tanto, faltava vivência pra entender de verdade os desafios que o livro descreve, o tipo de coisa que só experiência em projeto real ensina.

Tem também o estilo do autor: humor e paixão evidentes em quase toda página, o que torna a leitura mais leve do que se espera de um livro técnico de quase cinquenta anos.

O prazer de construir

Dá pra sentir esse entusiasmo logo nas primeiras páginas. Brooks fala do prazer de programar, da construção, chama de “a pura alegria de criar coisas”, e fica óbvio o quanto ele gosta disso. É provavelmente o que mais me atrai nessa área também: pegar algo do zero, ver funcionando, ver outra pessoa usando.

O mito do homem-mês

O título do livro vem da teoria do “homem mês”, uma unidade de medida do esforço de trabalho, usada para estimar prazo e custo de projetos. A ideia é que um projeto atrasado ganha mais gente e então anda mais rápido.

Parece óbvio hoje que isso não funciona. Me assusta pensar que era um raciocínio comum na época, e desconfio que ainda sobrevive em algumas empresas.

Cada sistema é diferente. Cada pessoa também, e a forma como elas interagem entre si muda tudo. Colocar alguém novo no meio de um projeto em andamento pode gerar mais problema do que solução, porque a comunicação fica mais difícil e os desentendimentos crescem exponencialmente com o número de gente envolvida.

Uma equipe pequena e alinhada bate uma equipe grande e desorganizada praticamente sempre. Mais não é melhor.

Planeje um para jogar fora

Brooks conta que engenheiros químicos descobriram, há muito tempo, que nenhum trabalho sai perfeito na primeira tentativa. Primeiro um modelo simplificado, depois o produto. Na engenharia de software, segundo ele, ainda não aprendemos essa lição direito. As primeiras versões mal funcionam. Muita coisa acaba sendo jogada fora para começar de novo.

Acho que isso mudou bastante. Metodologias ágeis pegaram, e hoje entregas frequentes e feedback constante viraram o padrão, não a exceção. Não lembro de ter trabalhado num projeto que foi construído e depois jogado fora inteiro, mas já vi alguns que mereciam.

Um caso que vivi: um projeto que levou dois anos para ser construído em AngularJS e, quando foi lançado, já estava obsoleto, porque o Angular 2 tinha acabado de sair. Foi em 2016. O sistema continua em produção até hoje (2024).

O todo e as partes

Esse capítulo abre com uma provocação: “Como alguém constrói um programa para funcionar?” Fala da importância de módulos fáceis de debugar e testar, e de como um controle de mudanças bem feito simplifica a manutenção.

Ler isso em 2024 é quase engraçado, essas práticas viraram básico. Nunca trabalhei sem controle de versão, tipo Git. Já trabalhei sem testes automatizados, só com uma equipe de QA testando tudo na mão. E também já vi o outro extremo: cobertura acima de 90%, mantida só pelos desenvolvedores, sem QA nenhum.

Sem bala de prata, essência e acidente na engenharia de software

Brooks fala da busca eterna por uma “bala de prata” que resolveria de vez os problemas da engenharia de software. Ele argumenta que isso é impossível. Não existe solução única para um problema que é, por natureza, complexo. Definir exatamente o que construir já é difícil o bastante.

Essa procura por solução mágica acompanhou minha carreira inteira. Editores inteligentes. Copiar e colar código. Frameworks que prometiam resolver tudo. Mais recentemente, inteligência artificial. Ajudam na produtividade. Continuo achando que a melhor solução é a mais simples para o problema que você tem na frente, não para o problema genérico que o framework da vez promete resolver.

Não existe bala de prata.

Conclusão

A lição de Brooks é que engenharia de software depende tanto de gente e processo quanto de código. Questões humanas e organizacionais precisam estar no centro. Para mim, o maior aprendizado do livro é que o sucesso de um projeto vem muito mais de boas práticas, comunicação e decisão bem tomada do que de ferramenta ou framework.

Se ainda não leu O Mítico Homem-Mês, recomendo. É um livro de 1975 que ainda descreve o trabalho.