Outro dia deixei um rascunho expirar no linkedin e ele foi publicado. Esse rascunho tinha uma tradução livre de um texto do Fred Brooks, de 1975 sobre “as alegrias” da arte de programar.

Deixo aqui outra tradução livre, desta vez dos “infortúnios” da arte de programar, da mesma obra. O Livro The Mythical Man-Month está disponível no Internet Archive.

Nem tudo é deleite, no entanto, conhecer os infortúnios inerentes torna mais fácil suportá-los quando surgem.

Primeiro, é necessário agir com perfeição. O computador se assemelha aos encantamentos das fábulas também nesse aspecto. Se um único caractere, uma única rima do encantamento não estiver estritamente correta, a magia não funciona. Os seres humanos não estão acostumados à perfeição, e poucas áreas da atividade humana a exigem, ajustar-se a essa exigência de perfeição é, creio eu, a parte mais difícil de aprender a programar.

Além disso outras pessoas determinam os objetivos, fornecem os recursos e oferecem as informações. Raramente se tem controle sobre as circunstâncias do próprio trabalho — ou mesmo sobre sua meta. Em termos de gestão, a autoridade que se tem não é suficiente para a responsabilidade assumida. Parece que, em todas as áreas os cargos nos quais as coisas realmente acontecem nunca têm autoridade formal à altura da responsabilidade. Na prática a autoridade real (em oposição à formal) é adquirida pelo próprio ímpeto da realização.

A dependência de outros tem um caso particular que é especialmente doloroso para o programador de sistemas: ele depende dos programas de outras pessoas. Estes, muitas vezes, são mal projetados, mal implementados, entregues de forma incompleta (sem código-fonte ou casos de teste) e mal documentados. Assim, ele precisa gastar horas estudando e corrigindo coisas que, num mundo ideal, estariam completas, disponíveis e utilizáveis.

O próximo infortúnio é que projetar grandes conceitos é divertido; encontrar pequenos bugs irritantes é apenas trabalho. Toda atividade criativa vem acompanhada de horas tediosas de esforço meticuloso, e com a programação não é diferente.

Em seguida, descobre-se que o processo de depuração avança com uma convergência linear — ou até pior —, quando se espera, de alguma forma, uma aproximação quadrática do fim. Assim, os testes se arrastam, e os últimos bugs difíceis levam mais tempo para serem encontrados do que os primeiros.

O último infortúnio — e, às vezes, a gota d’água — é que o produto sobre o qual alguém trabalhou tanto tempo parece obsoleto ao ser concluído (ou até antes disso). Colegas e concorrentes já estão em busca de ideias novas e melhores. A substituição do “filho mental” de alguém já está não só concebida, mas agendada.

Isso sempre parece pior do que realmente é. O novo e melhor produto geralmente não está disponível quando alguém conclui o seu próprio — apenas se fala sobre ele. Ele também exigirá meses de desenvolvimento. O tigre de verdade nunca é páreo para o de papel, a não ser que se deseje algo funcional. Nesse caso, as virtudes da realidade trazem uma satisfação única.

Claro que a base tecnológica sobre a qual se constrói está sempre avançando. Assim que se congela um projeto, ele se torna obsoleto em termos conceituais. Mas a implementação de produtos reais exige fases e quantizações. A obsolescência de uma implementação deve ser medida em relação a outras implementações existentes, e não a conceitos ainda não realizados. O desafio e a missão são encontrar soluções reais para problemas reais, em prazos reais, com recursos disponíveis.

Essa é, então, a programação — tanto um atoleiro em que muitos esforços naufragaram quanto uma atividade criativa com alegrias e dores muito próprias. Para muitos, as alegrias superam — e muito — os infortúnios.