The Mythical Man-Month

The Mythical Man-Month, de Frederick P. Brooks Jr., foi publicado em 1975 a partir da experiência do autor gerenciando o desenvolvimento do sistema operacional OS/360 da IBM. Quase cinquenta anos depois, continua sendo um dos livros mais citados da engenharia de software, justamente porque os problemas que ele descreve são menos sobre tecnologia e mais sobre pessoas, organização e a natureza do próprio software. Aqui estão cinco das ideias centrais do livro.

Comunicação e a Lei de Brooks

O título do livro vem do “mítico homem-mês”: a ideia de que pessoas e meses são intercambiáveis, e que dobrar a equipe divide o prazo pela metade. Brooks mostra que isso só vale para tarefas que podem ser divididas sem nenhuma comunicação entre quem as executa, como colher trigo. Software não é assim.

Primeiro, existem tarefas com restrições sequenciais que simplesmente não aceleram com mais gente. A comparação famosa: gerar um bebê leva nove meses, não importa quantas mulheres sejam designadas para isso. Segundo, cada pessoa nova precisa ser treinada, e quem treina são justamente as pessoas que já estão produzindo. Terceiro, o esforço de comunicação cresce muito rápido: se cada parte precisa se coordenar com todas as outras, n pessoas formam n(n−1)/2 canais de comunicação. Uma equipe de 3 tem 3 canais, uma de 10 tem 45.

Disso sai a Lei de Brooks: adicionar pessoas a um projeto de software atrasado o torna ainda mais atrasado.

No capítulo sobre a Torre de Babel, Brooks reforça o ponto: o projeto bíblico tinha objetivo claro, mão de obra, materiais e tempo, mas fracassou por falta de comunicação e, consequentemente, de organização. Ele defende que as equipes se comuniquem de todas as formas possíveis: informalmente, em reuniões regulares e através de um registro formal do projeto (o project workbook).

Equipe cirúrgica

Brooks parte de uma observação desconfortável: a diferença de produtividade entre bons e maus programadores é enorme, chegando a uma ordem de grandeza. A conclusão natural seria montar equipes pequenas só com os melhores. O problema é que uma equipe pequena, por mais brilhante que seja, é lenta demais para construir sistemas realmente grandes.

A solução que ele propõe (baseada em uma ideia de Harlan Mills) é organizar a equipe como uma equipe cirúrgica. Em vez de cada membro cortar um pedaço do problema, existe um cirurgião (o programador-chefe), que define a especificação, projeta e escreve o código, e um copiloto, que acompanha tudo, discute o design e pode substituí-lo. Ao redor deles, outras pessoas dão suporte: um administrador, um editor para a documentação, um responsável pelas ferramentas (o toolsmith), um testador, um especialista na linguagem e quem cuide dos registros do projeto.

A grande vantagem é que o sistema continua sendo produto de uma ou duas mentes, o que preserva a coerência do design, enquanto o trabalho braçal é distribuído. Também diminui muito a quantidade de canais de comunicação necessários, já que nem todos precisam negociar decisões de design entre si.

Integridade conceitual

Para Brooks, integridade conceitual é a consideração mais importante no design de um sistema. Ele usa a catedral de Reims como exemplo: construída ao longo de gerações, ela mantém uma unidade de estilo porque os construtores abriram mão das próprias ideias em favor do projeto original. A maioria dos sistemas de software, ao contrário, parece uma catedral construída por oito arquitetos diferentes, cada um adicionando suas próprias ideias.

Ele argumenta que é melhor um sistema omitir certas funcionalidades e refletir um único conjunto coerente de ideias do que ter muitas funcionalidades boas, mas independentes e descoordenadas. O que torna um sistema fácil de usar é a razão entre a funcionalidade que ele oferece e a complexidade conceitual que o usuário precisa aprender.

Para chegar nisso, o design precisa partir de uma única mente, ou de um grupo muito pequeno com a mesma visão. Por isso Brooks separa a arquitetura (a especificação completa do que o sistema faz, do ponto de vista do usuário) da implementação (como isso é feito). O arquiteto atua como representante do usuário. Brooks admite que isso soa “aristocrático”, mas defende que os implementadores continuam tendo bastante espaço criativo, só que no como, e não no o quê.

Ele também alerta para o efeito do segundo sistema: depois de projetar um primeiro sistema com cautela, o arquiteto tende a enfiar no segundo todas as ideias que guardou, criando o sistema mais inchado que vai projetar na vida.

Não existe bala de prata

Em 1986, Brooks escreveu o ensaio No Silver Bullet, depois incluído na edição de 20 anos do livro. A tese é direta: não existe nenhum avanço único, seja em tecnologia ou em gestão, que sozinho prometa sequer uma melhoria de uma ordem de grandeza em produtividade, confiabilidade ou simplicidade dentro de uma década.

Para defender isso, ele separa as dificuldades do software em dois tipos. A complexidade acidental vem das ferramentas e do processo de produção: linguagens de baixo nível, tempo de compilação, ambientes ruins. A complexidade essencial é inerente ao próprio problema que o software resolve. Os grandes ganhos do passado, como linguagens de alto nível, time-sharing e ambientes de desenvolvimento integrados, atacaram a complexidade acidental. Como sobrou pouca dela, nenhum avanço nessa frente vai trazer outro salto de dez vezes.

A complexidade essencial tem quatro propriedades que não desaparecem: complexidade (nenhuma parte se repete, e o número de estados possíveis é gigantesco), conformidade (o software precisa se adaptar a interfaces e instituições humanas arbitrárias), mutabilidade (software está sempre sob pressão para mudar) e invisibilidade (software não tem uma representação geométrica natural, o que dificulta raciocinar e se comunicar sobre ele).

Mesmo assim, Brooks aponta caminhos promissores para atacar a essência: comprar em vez de construir, refinar requisitos com prototipação rápida, cultivar o software de forma incremental em vez de construí-lo de uma vez, e, principalmente, identificar e desenvolver grandes designers.

Documentação

Brooks defende o que chama de hipótese documental: no meio de toda a papelada de um projeto, um pequeno conjunto de documentos se torna o eixo em torno do qual a gestão gira. Para um projeto de software, são eles: objetivos, especificações, cronograma, orçamento, organograma e alocação de espaço.

Escrever esses documentos tem três funções. Primeiro, escrever força decisões: só ao colocar as coisas no papel é que as lacunas e inconsistências aparecem. Segundo, os documentos comunicam essas decisões para os outros. Terceiro, servem como base de dados e checklist para o gerente, que pode revisá-los periodicamente para saber onde o projeto está e o que precisa mudar.

Ele também fala da documentação do próprio programa. Todo programa deveria vir acompanhado de uma descrição do seu propósito, do ambiente onde roda, das entradas e saídas, das funções que realiza, das opções disponíveis, do tempo de execução e da precisão esperada. E como documentação separada do código tende a ficar desatualizada, Brooks defende programas autodocumentados: incorporar a documentação ao próprio código-fonte, com bons nomes, estrutura clara e comentários, para que manter um signifique manter o outro.

Resumo gerado pelo Claude