Uma resenha de quase 50 anos
Nesta semana eu li “The Mythical Man-Month”, um livro que muitos listam, se não de leitura obrigatória, como o inicio da arte de engenharia de software e do pensamento no processo de construção de sistemas. Apesar de ser um livro bastante antigo (sua primeira versão foi publicada em 1975), é incrível notar como muitos dos problemas listados ainda são falados na comunidade de software, e o que mais me impressiona, como o conteúdo ainda aparece parafraseado nos slides daquele professor de engenharia ou projeto de sistemas.
Com 15 capítulos no original, e mais 4 de comentários posteriores em sua última edição de 1995, “The Mythical Man-Month” é um manifesto do que não se deve fazer, de como as coisas podem dar errado, e de como tudo que parece óbvio no desenvolvimento de software na verdade é sombrio e aterrador. Ainda assim, o livro nos traz uma visão romântica daquilo que ele chama de “integridade conceitual” de software, algo que me lembra o mundo das ideias de Platão, onde o nosso software existe como deveria ser, mas que nunca pode ser alcançada pela implementação.
É sim uma visão romântica, e principalmente estranha, uma vez que todo software entregue e finalizado deveria estar realizando aquilo que seu projeto inicial definiu, e logo nesse ponto 50 anos depois me parece que nada mudou. Ainda vemos muitos softwares não sendo entregues, concluídos fora do prazo e com especificações muito aquém daquelas originalmente projetadas (jogos com DLC no primeiro dia?). Como quase 50 anos se passaram sem que engenheiros tenham apreendido o que fazer?
A grande realidade, também tratada no livro, é que um projeto de software está a mercê de diversos valores externos, e não importa quão bom seja seu arquiteto, engenheiro ou estagiário, demandas insanas de prazo, funcionalidades e requisitos ainda são lugar comum na industria, mas de quem será a culpa?
Para tentar me aprofundar em alguns conceitos chave, eu separei o livro da seguinte forma:
Capitulo 1 ao 5: Pessoas são humanos, engenheiros são pessoas.
Logo são humanos? Está parte do livro se concentra principalmente em discorrer sobre como o projeto de software depende de pessoas, e como em geral elas estão muito mais desalinhadas do que parece. Logo no segundo capitulo temos a enunciação da lei de Brooks, o homônimo do livro, o mito do homem-mês.
Neste capitulo, Brooks argumenta que não se pode dimensionar um software em termos de homem-mês (como elogio a área, nunca ouvi ninguém usar este termo nos 22 anos que tenho de vida), uma vez que os não são intercambiáveis. Quatro homens não vão fazer o mesmo software em dois meses que dois outros fariam em 4, de fato minha observação anedótica é de que uma equipe de dois homens muito bem alinhados fazem o trabalho de uma equipe de 6 outros que ainda não estão entrosados, o que nos leva ao próximo conceito.
Capitulo 6 ao 10: Fale menos, escreva mais
Neste ponto o livro passa a tratar especificamente da comunicação dentro de um projeto de software. A analogia sobre porque a torre de babel falhou é especialmente interessante. O fato das pessoas não conseguirem se comunicar é o bastante para impedir a realização de um projeto? Mesmo que ele seja tão simples quanto uma torre que chegaria ao céu? A resposta é sim.
Comunicação é extremamente importante em qualquer projeto, mas ainda mais importante, se comunicar de forma eficiente é a chave. Estes conceitos tem me fascinado bastante, e para uma análise um pouco mais aprofundada sobre as dificuldades de comunicação, leia o meu artigo anterior.
Finalmente o capitulo 10 discorre sobre como mesmo após ser bem documentado, um software vai mudar durante seu ciclo de desenvolvimento, e sua documentação como consequência, e como isso deve ser previsto desde o inicio. Neste ponto é possível notar o que muitos dizem ser a gênese do modelo de prototipagem e mais tarde dos modelos de desenvolvimento ágil.
Capitulo 11 ao 14: E agora, ta tudo errado?
Sim, tem bastante coisa errada. Esta talvez seja a parte mais mórbida do livro. Nestes capítulos o autor trata sobre como os erros se acumulam em um projeto, para finalmente estourarem todos juntos quando já é impossível resolve-los em tempo hábil. É claro que alguns dos pontos colocados neste momento parecem histórias estranhas para quem trabalha com desenvolvimento de software nos dias atuais (gerenciar tempo compartilhado?), outro já são considerados lugar comum (diagramas de fluxo não servem), porém o maior problema são aqueles que tem respostas mas são ignorados. Por que não se tornou lugar comum produzir documentação de software? Isso evitaria uma serie de problemas encontrados durante um projeto, e forneceria meios de resolver problemas futuros, e esse é um dos pontos que mais me anima no momento, com ferramentas de wiki sendo integradas em projetos, geradores automáticos de documentação para API’s, entre outras ferramentas.
Capitulo 15 ao 19: Conclusão, de novo e outra vez
No final do livro, finalmente temos uma visão do que pode ser (e do futuro vemos o que foi). Discorrendo sobre novas técnicas de orientação a objetos, modelos de desenvolvimento iterativos, e até mesmo adoção de linguagens de alto nível, eu diria que este é o ponto onde o livro menos acrescenta para quem desenvolve software nos dias atuais, uma vez que todas as novidades apresentadas, nenhuma a bala de prata para resolver todos os problemas monstruosos, estes são também os capítulos que servem para validar tudo o que veio antes. Na primeira vez em 1975, para então retornar em 1990, é interessante notar como Brooks tinha uma visão realista e bastante concreta, se não preditora, de todo o desenvolvimento de software nos anos posteriores.
Embora as conclusões sejam hoje premissas, conhecidas assim que se entra no mundo do desenvolvimento, muitos dos problemas anteriores descritos no livro são atuais, e a visão que o autor nos mostra traz a tona coisas que observamos mas não compreendemos.
Leitura fortemente recomendada.
