Clássicos III

O próximo na esporadiquíssima* série de papers clássicos é o "No Silver Bullet: Essence and Accidents of Software Engineering" (html, pdf), escrito pelo Fred Brooks, um pioneiro da engenharia de software. Entre outros feitos, ele foi o gerente do desenvolvimento do IBM OS/360, escreveu o também clássico livro The Mythical Man-Month, onde cunhou a famosa lei de brooks e recebeu o prêmio Turing de 1999.

O paper "No Silver Bullet" foi publicado originalmente em 1986 e tem, mais do que seus antecessores nesta série, um certo ar antigo, decerto produto das muitas referências a tecnologias oitentistas. Isso não significa de modo algum que esteja obsoleto, visto que as décadas posteriores confirmaram seguidas vezes a tese principal do artigo. Essa tese pode ser resumida na constatação de que muitas das dificuldades envolvidas no processo de desenvolvimento de software são essenciais, portanto é impossível que qualquer avanço técnico consiga uma melhoria de sequer uma ordem de magnitude na produtividade, confiabilidade ou simplicidade.

Essa proposição sem dúvida é importante, e serve como um bom antídoto para os venenos dos vendedores de elixires mágicos para a produtividade. Eu, entretanto, aprecio mais outros aspectos desse texto: ele não é longo, mas é pontuado por pérolas de experiência. Cito algumas, começando por esse trecho extraído da discussão sobre a complexidade de software:

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.

Uma diretriz importante no desenvolvimento de software é minimizar a repetição (uma formulação mais imperativa desse princípio veio dos pragmatic programmers - Don't Repeat Yourself - DRY - com acrônimo e tudo). Isso quer dizer que, ao menos em teoria, ao analisar um sistema de grande porte, todo detalhe é significativo; cada linha deve representar o produto de um trabalho intelectual. Compare com um grande arranha-céu**, por exemplo. Não se trata de menosprezar os construtores - certamente existem desafios consideráveis em projetos civís dessa escala - mas me parece claro que o trabalho intelectual para construir dois andares não é o dobro do envolvido na construção de apenas um. Não obstante, os pedreiros*** tem de suar a camisa para de fato botar estes tais andares em pé. Incrívelmente, muita gente não percebe essa diferença fundamental e tenta tratar programadores como trabalhadores braçais, limitados a seguir as instruções de um ser superior ocupando um cargo pomposo (atualmente "arquiteto" é popular, mas "analista de sistemas" já foi o título mais comum).
Ainda sobre complexidade:

Much of the complexity that he [the software developer] must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God.

Em outras palavras "it's the requirements, stupid!". Uma das qualidades do software é a precisão; qualquer programa faz exatamente o que o programador manda, e nada mais. E isso é ótimo, pois abre a possibilidade para enormes ganhos de qualidade ao automatizar processos de negócios. E também é aí que a porca torce o rabo****, pois é surpreendentemente complicado traduzir estes processos, e seus dados, em especificações que computadores consigam entender. Isso porque as informações difícilmente estão em formato suficientemente exato para alimentar o desenvolvimento de software; costumam ser imprecisas, ambíguas e, frequentemente, inexistentes. Essa é razão da pujança de empresas como a SAP e os outros 500 bilhões fabricantes de ERPs.*****

Vou parar por aqui, pois este comentário já esta longo demais. No decorrer do texto, Brooks levanta algumas das principais dificuldades essenciais e desconstrói vários candidados a silver bullet, mostrando como eles tratam apenas das difuldades acidentais, sem aliviar as essenciais. Nesse caminho encontramos uma diversidade de conceitos interessantes (a própria nomenclatura de dificuldades acidentais vs essenciais já é de grande valia) e idéias que instigam reflexão.
EDIT: Esqueci do mais importante: RTFA!


* Será que essa palavra já foi escrita alguma vez antes? Espero que ninguém mais comita esse crime... Eca.
** Já escrevendo em português, às vezes a gente não tem o mesmo cuidado...
*** Tenho a impressão que esse termo não é políticamente correto, mas não consegui arranjar um substituto adequado. Se alguém se sentiu ofendido, por favor escreva um email para bite@me.com
**** Continuando a minha irrefletida e irrefreável busca por originalidade, torço para que esta seja a primeira (e a última) vez que a expressão "a porca torce o rabo" aparece num texto sobre engenharia de software...
***** É bem verdade que nem todas são tão bem-sucedidas como a SAP...