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

Resumo

Um livro publicado pela primeira vez em 1975, e ainda se mantém relevante para profissionais de software. Fred Brooks aborda temas que vão além do código, explorando questões como gerenciamento de projetos, comunicação em equipes, complexidade de sistemas e muito mais.

A obra me trouxe diversas reflexões sobre os desafios da engenharia de software, com insights que, surpreendentemente, continuam valiosos mesmo após décadas. Abaixo compartilho alguns aprendizados que tive enquanto lia, em ordem cronológica do livro.

Introdução

Essa foi a primeira (definitivamente não será a única) vez que li o livro, em outubro de 2024, acredito que não teria aproveitado e entendido tanto o livro se tivesse lido no começo da minha carreira. A experiência de trabalho e a vivência em projetos de software me permitiram compreender melhor os desafios e problemas que o livro aborda.

Além disso, o autor tem um estilo bem-humorado e muito apaixonado, fazendo com que a leitura seja muito agradável e inspiradora.

O prazer de construir

Logo nas primeiras páginas, o autor fala sobre o prazer de programar, da construção, “a pura alegria de criar coisas”, é possível perceber o quanto ele gosta de programar. Acredito que essa seja uma das coisas que mais me atrai na área de desenvolvimento de software, a possibilidade de criar algo do zero, de ver algo funcionando e sendo utilizado por outras pessoas.

O mito do homem-mês

O título do livro é baseado na teoria do “homem mês”, que seria uma unidade de medida para o esforço de trabalho, usado para estimar prazos e custos de projetos. A ideia é que um projeto levaria menos tempo para ser concluído ao adicionar mais pessoas na equipe.

Na minha visão parece muito óbvio que isso não funciona, me assusta imaginar ser um pensamento comum na época, e que talvez ainda seja em algumas empresas.

Todos os sistemas são diferentes, as pessoas são diferentes, assim como a interação entre elas. Adicionar um novo integrante a uma equipe durante um projeto pode causar mais problemas do que soluções. A dificuldade de comunicação e quantidade de desentendimentos cresce exponencialmente com o número de pessoas envolvidas.

Uma equipe menor, mas bem alinhada será sempre mais eficiente do que uma equipe grande e desorganizada. Mais não é melhor

Planeje um para jogar fora

O autor descreve como engenheiros químicos descobriram há muito tempo que não é possível um trabalho ser implementado em apenas um passo, necessário começar com um modelo simplificado até evoluir para o produto final. Na engenharia de software, ele escreve que ainda não aprendemos essa lição. Muitas das primeiras versões mal chegam a ser utilizáveis, e que não tem alternativa a não ser jogar fora e começar do zero.

Acredito que isso é algo que já mudou bastante, com a popularização de metodologias, projetos de software são desenvolvidos de forma iterativa, com entregas frequentes e feedback constante. Não me recordo de ter trabalhado em um projeto que tenha sido desenvolvido e na sequência jogado fora, mas já vi alguns que deveriam.

Um caso emblemático, em que trabalhei, foi um projeto desenvolvido durante 2 anos utilizando AngularJS, que quando foi lançado, já estava obsoleto, pois o Angular 2 já estava disponível. Isso ocorreu em 2016, e o sistema continua em produção hoje (2024).

O todo e as partes

Esse capítulo começa com uma provocação, “Como alguém constrói um programa para funcionar?”, e fala sobre importância de criar módulos fáceis de debugar e testar, e como o controle de mudanças facilita na manutenção do sistema.

É até divertido ler sobre esses assuntos em 2024, já que muitas dessas práticas são amplamente adotadas. Nunca atuei em um projeto sem um controle de versionamento (como Git), porém já atuei em projetos que não tinham testes automatizados, porém havia uma equipe de teste, que os realizavam manualmente. Por outro lado, já trabalhei em projetos onde a cobertura de testes era acima de 90%, mantido somente pelos desenvolvedores.

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

Brooks fala sobre a busca por uma “bala de prata”, que solucione os problemas da engenharia de software, e argumenta como isso é impossível, pois não existe uma solução que vá resolver todos os problemas. A engenharia de software é intrinsecamente complexo, definir exatamente o que é necessário construir acaba sendo desafiador, com infinitas maneiras de fazê-lo.

Essa busca constante por soluções mágicas sempre esteve muito presente na minha carreira, editores inteligentes, copiar e colar códigos, frameworks mágicos, e mais recentemente, inteligência artificial. Essas ferramentas podem e ajudam na produtividade, mas continuo acreditando que a melhor solução vai ser sempre a mais simples para o problema que você está tentando resolver. A própria natureza nos mostra que a diversidade e constante “evolução” são o segredo. Não existe bala de prata.

Conclusão

Fred Brooks nos ensina que a engenharia de software é sobre pessoas e processos, e não apenas sobre código. Questões humanas e organizacionais sempre devem estar no centro. Para mim a maior lição do livro é que o sucesso de um projeto vai depender muito mais de boas práticas, comunicação e decisões do que ferramentas e frameworks.

Se você ainda não leu O Mítico Homem-Mês, recomendo fortemente. É um clássico atemporal que não apenas ilumina o passado do desenvolvimento de software, mas também oferece reflexões valiosos para o futuro.