Em 1975, Frederick P. Brooks escreveu The Mythical Man-Month (O Mítico Homem-Mês), um dos livros mais conhecidos, revolucionários e controversos sobre desenvolvimento de software.

Eu seu livro, Brooks reúne grande parte de seu conhecimento sobre Engenharia de Software. Baseado em conceitos fundamentais da computação e na experiência prática de ter gerenciado um dos maiores projetos de desenvolvimento de sua época, o autor fez várias afirmações sobre o então presente e futuro do desenvolvimento de software.

Vinte anos depois, em 1995, seu livro ganhou uma nova edição e capítulos adicionais. Um deles revisa de forma sistemática cada proposição do autor e acrescenta comentários sobre sua validade. A questão é: após anos de prática de Engenharia de Software, permanecem as afirmações consistentes ou foram desmistificadas por novos conhecimentos, descobertas e experimentos? Em outro capítulo, o autor novamente revisa os argumentos principais do livro. Ele reconhece quando estava errado? Quais argumentos estão obsoletos?

Hoje, quarenta anos depois da primeira edição de The Mythical Man-Month, gostaria de novamente revisar as afirmações e os argumentos de Brooks. Juntos, vamos então compará-las com as práticas modernas da Engenharia de Software.

Como vai funcionar

Irei publicar um artigo para cada capítulo do livro, começando a partir deste que inclui o capítulo 1.

Irei descrever os principais argumentos do autor em cada um dos capítulos. Usarei como guia o capítulo 18 da edição de aniversário de Mythical Man-Month, Propositions of The Mythical Man-Month: True or False?, que já contém um resumo das proposições feitas pelo autor.

Para cada proposição principal, adicionarei comentários ou explicações, de acordo com a obviedade ou não da mesma. O leitor notará que muitas das proposições são obviamente verdadeiras ou auto-explicativas. Não adentrarei em detalhes nesses casos.

Ao final de cada artigo, farei uma síntese sobre os pontos, destacando os que ainda são válidos hoje, parcialmente válidos (dentro de certo contexto, por exemplo), os que já foram ultrapassados pelo tempo ou que não se mostraram verdadeiros.

Capítulo 1: The Tart Pit

Neste capítulo, Brooks inicia sua argumentação com uma analogia: o desenvolvimento de grandes sistemas de software é tão difícil como foi para os grandes e pesados animais da pré-história libertarem-se de um poço de piche, muitos sucumbiram e foram tragados. Quantos projetos grandes e pequenos, com equipes massivas ou enxutas, não foram abandonados ou cancelados sem conseguir avançar para seu objetivo?

É necessário 3 vezes mais esforço para desenvolver um componente de software em relação a um software para uso privado, assim como 3 vezes mais esforço para transformá-lo em um produto coerente e testado.

É muito difícil, se não impossível, avaliar a afirmação acima com exatidão. O bom senso diz que isso varia de acordo com as características do projeto. Entretanto, é patente que o princípio por detrás dela é pura verdade.

Por exemplo, um desenvolvedor pode criar um script para uso pessoal muito rapidamente. Mas se ele quiser publicar aquele script para os colegas reusarem, vai precisar modificá-lo para atender casos mais genéricos e parametrizar as informações que era fixas em um ambiente. Talvez ele precise definir uma API, escrever alguma documentação ou mesmo uma GUI consistente. Outro passo seria transformar isto numa ferramenta para uso de qualquer interessado em outras empresas e ambientes. Um produto de software vai demandar muito mais esforço.

Particularmente eu diria que o fator de 9 vezes para transformar um software privado em um produto coerente é ainda conservador, se considerarmos todos os aspectos como hospedagem e suporte. Testes automatizados ou manuais também somam-se ao custo da qualidade do produto.

A profissão de programar envolve gratificação pessoal: a alegria de construir as coisas.

A afirmação nunca foi tão verdadeira.

Vemos movimentos como agile e software craftsmanship reforçando esta ideia. A experiência cotidiana também.

Os melhores desenvolvedores são pessoas que amam o que fazem. Embora até possam existir gênios que aprendem sem muito esforço, aqueles que mais se destacam são os que acreditam no que fazem e se esforçam diariamente.

A profissão também envolve sofrimento

Brooks afirma que programadores precisam se adaptar ao nível de perfeição exigido, isto é, programar software sem erros pois o computador não tolera pequenas falhas, o que é muito difícil e penoso no começo.

Programadores em geral têm seus objetivos definidos por outros e depende de outras pessoas para atingi-lo. Eles não podem controlar a situação e não tem autoridade necessária para fazer as coisas acontecerem na grande maioria dos casos.

Brooks ainda lembra que para cada momento de criatividade para projetar algo é posteriormente acompanhando por horas e mais horas de trabalho desgastante para atingir o objetivo. É como quando assistimos a uma conferência e saímos cheios de ideias, mas o trabalho para colocar tudo em prática nos desestimula completamente.

O projeto de software converge mais de vagar na medida em que chega ao fim. Muitos pensam que é possível acelerar o desenvolvimento com a experiência que a equipe acumula no decorrer do projeto, mas em geral ocorre o oposto, já que muitas atividades ocultas são descobertas, bugs se acumulam e a base de código e a complexidade crescem.

Por fim, muitos dos produtos de software são ameaçados de obsolescência antes mesmo de estarem completos. O motivo é que as necessidades mudam constantemente e qualquer implementação começa a se tornar obsoleta no momento em que foi realizada. Ajustamos constantemente o nosso entendimento e até o projeto de um sistema, sendo que geralmente não é possível evoluir as implementações na mesma velocidade.

Considerações sobre o capítulo

Este é apenas um capítulo introdutório sobre pontos gerais relacionados aos problemas do desenvolvimento de software e ao ofício relativo a ele. Talvez por isso, em maior ou menor grau, todos os pontos são tão ou mais relevantes e verdadeiros hoje em relação a 1975.

Essa conclusão com certeza dá um gosto especial para apreciarmos os demais capítulos, para os quais publicarei comentários em breve.

Não percam! 😀