Assine o DeepL Pro para traduzir arquivos maiores.

Mais informações em www.DeepL.com/pro.

Sem bala de prata

-Essência e acidente na engenharia de software

Frederick P. Brooks, Jr.

Universidade da Carolina do Norte em Chapel Hill

Não existe um desenvolvimento único, seja em tecnologia ou em técnica de

gerenciamento, que por si só prometa uma melhoria de uma ordem de
magnitude em uma década em termos de produtividade, confiabilidade e
simplicidade.

Resumo1
Toda a construção de software envolve tarefas essenciais, a formação de estruturas
conceituais complexas que compõem a entidade abstrata do software, e tarefas acidentais,
a representação dessas entidades abstratas em linguagens de programação e o
mapeamento delas em linguagens de máquina dentro das restrições de espaço e
velocidade. A maior parte dos grandes ganhos do passado em produtividade de software
veio da remoção de barreiras artificiais que t o r n a r a m as tarefas acidentais
extremamente difíceis, como restrições severas de hardware, linguagens de programação
complicadas e falta de tempo de máquina. Quanto do que os engenheiros de software
fazem atualmente ainda é dedicado ao acidental, em oposição ao essencial? A menos que
seja mais de 9/10 de todo o esforço, reduzir todas as atividades acidentais a tempo zero
não proporcionará uma melhoria de ordem de magnitude.
Portanto, parece que chegou a hora de abordar as partes essenciais da tarefa de
software, aquelas relacionadas à criação de estruturas conceituais abstratas de grande
complexidade. Eu sugiro:
• Explorar o mercado de massa para evitar a construção do que pode ser comprado.
• Usar a prototipagem rápida como parte de uma iteração planejada no estabelecimento
de requisitos de software.
• O software cresce organicamente, acrescentando cada vez mais funções aos sistemas à
medida que eles são executados, usados e testados.
• Identificar e desenvolver os grandes designers conceituais da nova geração.

Introdução
De todos os monstros que enchem os pesadelos de nosso folclore, nenhum aterroriza
mais do que os lobisomens, porque eles se transformam inesperadamente do familiar em
horrores. Para eles, buscamos balas de prata que possam magicamente fazê-los descansar.

1 Reproduzido de: Frederick P. Brooks, The Mythical Man-Month, edição de aniversário com 4 novos
capítulos, Addison-Wesley (1995), reproduzido dos Proceedings of the IFIP Tenth World Computing
Conference, H.-J. Kugler, ed., Elsevier Science B.V., Amsterdam, NL (1986) pp. 1069-76.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 2

O conhecido projeto de software tem um pouco desse caráter (pelo menos na visão do
gerente não técnico), geralmente inocente e direto, mas capaz de se tornar um monstro de
cronogramas não cumpridos, orçamentos estourados e produtos defeituosos. Portanto,
ouvimos gritos desesperados por uma bala de prata, algo que faça com que os custos de
software caiam tão rapidamente quanto os custos de hardware de computador.
Mas, ao olharmos para o horizonte da próxima década, não vemos nenhuma bala de
prata. Não existe um desenvolvimento único, seja em tecnologia ou em técnica de
gerenciamento, que por si só prometa uma melhoria de uma ordem de magnitude em
produtividade, confiabilidade e simplicidade. Neste capítulo, tentaremos entender o
porquê, examinando a natureza do problema do software e as propriedades das soluções
propostas.
Entretanto, ceticismo não é pessimismo. Embora não vejamos nenhuma descoberta
surpreendente e, de fato, acreditemos que isso seja inconsistente com a natureza do
software, muitas inovações encorajadoras estão em andamento. Um esforço disciplinado
e consistente para desenvolvê-las, propagá-las e explorá-las deve, de fato, produzir uma
melhoria de ordem de magnitude. Não existe uma estrada real, mas existe uma estrada.
O primeiro passo para o controle de doenças foi a substituição das teorias dos
demônios e dos humores pela teoria dos germes. Esse mesmo passo, o início da
esperança, por si só acabou com todas as esperanças de soluções mágicas. Ela dizia aos
trabalhadores que o progresso seria feito por etapas, com grande esforço, e que seria
necessário um cuidado persistente e incessante com uma disciplina de limpeza. O mesmo
acontece com a engenharia de software atualmente.

Tem que ser difícil? - Dificuldades essenciais

Além de não haver nenhuma bala de prata no momento, a própria natureza do software
torna improvável que haja alguma - nenhuma invenção que faça pela produtividade,
confiabilidade e simplicidade do software o que a eletrônica, os transistores e a
integração em larga escala fizeram pelo hardware do computador. Não podemos esperar
ver ganhos duas vezes maiores a cada dois anos.
Primeiro, devemos observar que a anomalia não está no fato de o progresso do
software ser tão lento, mas no fato de o progresso do hardware do computador ser tão
rápido. Nenhuma outra tecnologia, desde o início da civilização, teve um ganho de preço-
desempenho de seis ordens de magnitude em 30 anos. Em nenhuma outra tecnologia é
possível escolher entre o ganho em desempenho aprimorado ou em custos reduzidos.
Esses ganhos decorrem da transformação da fabricação de computadores de um setor de
montagem em um setor de processos.
Em segundo lugar, para ver qual é a taxa de progresso que podemos esperar da
tecnologia de software, vamos examinar suas dificuldades. Seguindo Aristóteles, eu as
divido em essência - as dificuldades inerentes à natureza do software - e acidentes -
aquelas dificuldades que hoje acompanham sua produção, mas que não são inerentes.
Discutirei os acidentes na próxima seção. Primeiro, vamos considerar a essência.
A essência de uma entidade de software é uma construção de conceitos interligados:
conjuntos de dados, relacionamentos entre itens de dados, algoritmos e invocações de
funções. Essa essência é abstrata, pois a construção conceitual é a mesma em muitas
representações diferentes. No entanto, ela é altamente precisa e rica em detalhes.
Acredito que a parte difícil da criação de software seja a especificação, o projeto e o
teste dessa construção conceitual, e não o trabalho de representá-la e testar a fidelidade da
representação. Ainda cometemos erros de sintaxe, com certeza, mas eles são
insignificantes em comparação com os erros conceituais da maioria dos sistemas.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 3

Se isso for verdade, a criação de software sempre será difícil. Não há, inerentemente,
uma bala de prata.
Vamos considerar as propriedades inerentes a essa essência irredutível dos sistemas
de software modernos: complexidade, conformidade, capacidade de mudança e
invisibilidade.

Complexidade. As entidades de software são mais complexas para seu tamanho do que
talvez qualquer outra construção humana, porque não há duas partes iguais (pelo menos
acima do nível de instrução). Se forem, transformamos as duas partes semelhantes em
uma só, uma sub-rotina, aberta ou fechada. Nesse aspecto, os sistemas de software
diferem profundamente de computadores, edifícios ou automóveis, onde há muitos
elementos repetidos.
Os computadores digitais são mais complexos do que a maioria das coisas que as
pessoas constroem; eles têm um número muito grande de estados. Isso dificulta a
concepção, a descrição e os testes. Os sistemas de software têm ordens de magnitude
mais estados do que os computadores.
Da mesma forma, o aumento de escala de uma entidade de software não é apenas uma
repetição dos mesmos elementos em tamanho maior; é necessariamente um aumento no
número de elementos diferentes. Na maioria dos casos, os elementos interagem uns com
os outros de forma não linear, e a complexidade do todo aumenta muito mais do que
linearmente.
A complexidade do software é uma propriedade essencial, não acidental. Por isso, as
descrições de uma entidade de software que abstraem sua complexidade geralmente
abstraem sua essência. A matemática e as ciências físicas fizeram grandes avanços
durante três séculos, construindo modelos simplificados de fenômenos complexos,
derivando propriedades dos modelos e verificando essas propriedades
experimentalmente. Isso funcionou porque as complexidades ignoradas nos modelos não
eram as propriedades essenciais dos fenômenos. Não funciona quando as complexidades
são a essência.
Muitos dos problemas clássicos do desenvolvimento de produtos de software derivam
dessa complexidade essencial e de seu aumento não linear com o tamanho. Da
complexidade vem a dificuldade de comunicação entre os membros da equipe, o que leva
a falhas no produto, custos excedentes e atrasos no cronograma. Da complexidade vem a
dificuldade de enumerar, e muito menos de entender, todos os estados possíveis do
programa, e daí vem a falta de confiabilidade. Da complexidade das funções vem a
dificuldade de invocá-las, o que torna os programas difíceis de usar. Da complexidade da
estrutura vem a dificuldade de estender os programas a novas funções sem criar efeitos
colaterais. Da complexidade da estrutura vem o estado não visualizado que constitui uma
armadilha de segurança.
Não apenas os problemas técnicos, mas também os problemas de gerenciamento
decorrem da complexidade. Essa complexidade dificulta a visão geral, impedindo assim a
integridade conceitual. Torna difícil encontrar e controlar todas as pontas soltas. Ela cria
uma enorme carga de aprendizado e compreensão que torna a rotatividade de pessoal um
desastre.

Conformidade. As pessoas que trabalham com software não são as únicas a enfrentar a
complexidade. A física lida com objetos terrivelmente complexos, mesmo no nível das
partículas "fundamentais". O físico trabalha, no entanto, com a firme convicção de que há
princípios unificadores a serem encontrados, seja nos quarks ou nas teorias de campo
unificado. Einstein argumentou repetidamente que deve haver explicações simplificadas
da natureza, porque Deus não é caprichoso ou arbitrário.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 4

Essa fé não conforta o engenheiro de software. Grande parte da complexidade que ele
precisa dominar é uma complexidade arbitrária, forçada sem rima ou razão pelos muitos
fatores humanos que o tornam um profissional de software.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 5

instituições e sistemas para os quais suas interfaces devem confirmar. Elas diferem de
interface para interface e de tempos em tempos, não por necessidade, mas apenas porque
foram projetadas por pessoas diferentes, e não por Deus.
Em muitos casos, o software deve confirmar porque entrou em cena mais
recentemente. Em outros, ele deve estar em conformidade porque é percebido como o
mais adaptável. Mas, em todos os casos, grande parte da complexidade vem da
conformidade com outras interfaces; isso não pode ser simplificado apenas com um
redesenho do software.

Capacidade de mudança. A entidade de software está constantemente sujeita a pressões

por mudanças. É claro que edifícios, carros e computadores também estão. Mas os
produtos manufaturados raramente são alterados após a fabricação; eles são substituídos
por modelos posteriores ou alterações essenciais são incorporadas em cópias posteriores
com número de série do mesmo projeto básico. As chamadas de retorno dos automóveis
são realmente muito raras; as mudanças de campo dos computadores, um pouco menos.
Ambas são muito menos frequentes do que as modificações no software em campo.
Em parte, isso se deve ao fato de o software em um sistema incorporar sua função, e a
função é a parte que mais sente as pressões da mudança. Em parte, isso se deve ao fato de
que o software pode ser alterado com mais facilidade - ele é puro material de pensamento,
infinitamente maleável. Os edifícios são, de fato, alterados, mas os altos custos da
mudança, compreendidos por todos, servem para amortecer o capricho dos alteradores.
Todo software bem-sucedido é alterado. Dois processos estão em ação. À medida que
se descobre que um produto de software é útil, as pessoas o testam em novos casos no
limite do domínio original ou além dele. As pressões para ampliar a função vêm
principalmente dos usuários que gostam da função básica e inventam novos usos para ela.
Em segundo lugar, o software bem-sucedido também sobrevive além da vida útil
normal do veículo da máquina para o qual foi escrito pela primeira vez. Se não forem
novos computadores, pelo menos novos discos, novas telas e novas impressoras surgirão,
e o software deverá ser adaptado a seus novos veículos de oportunidade.
Em resumo, o produto de software está incorporado em uma matriz cultural de
aplicativos, usuários, leis e veículos de máquinas. Todos eles mudam continuamente, e
suas mudanças inexoravelmente forçam mudanças no produto de software.

Invisibilidade. O software é invisível e não pode ser visualizado. As abstrações

geométricas são ferramentas poderosas. A planta baixa de um edifício ajuda o arquiteto e
o cliente a avaliar espaços, fluxos de tráfego e vistas. As contradições se tornam óbvias e
as omissões podem ser detectadas. Desenhos em escala de peças mecânicas e modelos de
moléculas em forma de bastão, embora sejam abstrações, têm a mesma finalidade. Uma
realidade geométrica é capturada em uma abstração geométrica.
A realidade do software não está inerentemente incorporada ao espaço. Portanto, ele
não tem uma representação geométrica pronta, da mesma forma que a terra tem mapas,
chips de silício têm diagramas, computadores têm esquemas de conectividade. Assim que
tentamos diagramar a estrutura do software, descobrimos que ela constitui não um, mas
vários gráficos gerais direcionados, sobrepostos uns aos outros. Os vários gráficos podem
representar o fluxo de controle, o fluxo de dados, os padrões de dependência, a sequência
temporal, as relações nome-espaço. Em geral, eles não são nem mesmo planares, muito
menos hierárquicos. De fato, uma das formas de
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 6

estabelecer o controle conceitual sobre essa estrutura é impor o corte de links até que um
ou mais gráficos se tornem hierárquicos.2
Apesar do progresso em restringir e simplificar as estruturas do software, elas
permanecem inerentemente não visualizáveis, privando a mente de algumas de suas
ferramentas conceituais mais poderosas. Essa falta não apenas impede o processo de
design em uma mente, mas também dificulta muito a comunicação entre as mentes.

Descobertas anteriores resolveram dificuldades acidentais

Se examinarmos as três etapas da tecnologia de software que foram mais frutíferas no
passado, descobriremos que cada uma delas atacou uma grande dificuldade diferente na
criação de software, mas foram as dificuldades acidentais, não as essenciais. Também
podemos ver os limites naturais para a extrapolação de cada um desses ataques.

Linguagens de alto nível. Certamente, o golpe mais poderoso para a

produtividade, confiabilidade e simplicidade do software foi o uso progressivo de
linguagens de alto nível para programação. A maioria dos observadores credita a esse
desenvolvimento pelo menos um fator de cinco na produtividade e com ganhos
concomitantes em confiabilidade, simplicidade e compreensibilidade. O que uma
linguagem de alto nível faz? Ela libera um programa de grande parte de sua
complexidade acidental. Umprograma abstrato consiste em construções conceituais:
operações, tipos de dados, sequências e comunicação. O programa concreto da máquina
está relacionado a bits, registros, condições, ramificações, canais, discos e outros. Na
medida em que a linguagem de alto nível incorpora as construções desejadas no programa
abstrato e evita todas a s inferiores, ela elimina todo um nível de complexidade que era
nunca foi inerente ao programa.
O máximo que uma linguagem de alto nível pode fazer é fornecer todas as
construções que o programador imagina em um programa abstrato. Sem dúvida, o nível
de nossa sofisticação no pensamento sobre estruturas de dados, tipos de dados e
operações está aumentando constantemente, mas a uma taxa cada vez menor. E o
desenvolvimento da linguagem está cada vez mais próximo da sofisticação dos usuários.
Além disso, em algum momento, a elaboração de uma linguagem de alto nível se
torna um fardo que aumenta, e não reduz, a tarefa intelectual do usuário que raramente
usa as construções esotéricas.

Compartilhamento de tempo. A maioria dos observadores atribui ao compartilhamento

de tempo uma grande melhoria na produtividade dos programadores e na qualidade de
seus produtos, embora não tão grande quanto a trazida pelas linguagens de alto nível.
O compartilhamento de tempo ataca uma dificuldade distintamente diferente. O
compartilhamento de tempo preserva o imediatismo e, portanto, nos permite manter uma
visão geral da complexidade. A lentidão da programação em lote significa que
inevitavelmente esquecemos as minúcias, se não a própria essência, do que estávamos
pensando quando paramos de programar e solicitamos a compilação e a execução. Essa
interrupção da consciência custa caro em termos de tempo, pois precisamos nos atualizar.
O efeito mais grave pode muito bem ser a diminuição da compreensão de tudo o que está
acontecendo em um sistema complexo.

2Parnas, D.L., "Designing software for ease of extension and contraction", IEEE Trans. on SE, 5, 2
(março de 1979), pp. 12-138.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 7

A lentidão no retorno, assim como as complexidades da linguagem de máquina, é

uma dificuldade acidental e não essencial do processo de software. Os limites da
contribuição do compartilhamento de tempo derivam diretamente. O principal efeito é
reduzir o tempo de resposta do sistema. À medida que ele se aproxima de zero, em algum
momento ele ultrapassa o limite humano de percepção, cerca de 100 milissegundos. Além
disso, não se espera nenhum benefício.

Ambientes de programação unificados. O Unix e o Interlisp, os primeiros ambientes de

programação integrados a entrar em uso generalizado, são considerados como tendo
aumentado a produtividade por fatores integrais. Por quê?
Eles atacam as dificuldades acidentais de usar programas em conjunto, fornecendo
bibliotecas integradas, formatos de arquivo unificados e pilhas e filtros. Como resultado,
as estruturas conceituais que, em princípio, sempre poderiam chamar, alimentar e usar
umas às outras podem, de fato, fazer isso facilmente na prática.
Essa descoberta, por sua vez, estimulou o desenvolvimento de bancos de ferramentas
inteiros, pois cada nova ferramenta podia ser aplicada a qualquer programa usando os
formatos padrão.
Devido a esses sucessos, os ambientes são o tema de grande parte das pesquisas
atuais em engenharia de software. Analisaremos suas promessas e limitações na próxima
seção.

Esperanças para o Silver

Agora vamos considerar os desenvolvimentos técnicos que são mais frequentemente
apresentados como possíveis balas de prata. Que problemas eles abordam? São os
problemas essenciais ou são remanescentes de nossas dificuldades acidentais? Eles
oferecem avanços revolucionários ou incrementais?

Ada e outros avanços em linguagens de alto nível. Um dos desenvolvimentos recentes

mais elogiados é a linguagem de programação Ada, uma linguagem de alto nível e de
propósito geral da década de 1980. De fato, a Ada não apenas reflete melhorias
evolutivas nos conceitos de linguagem, mas incorpora recursos para incentivar conceitos
modernos de design e modularização. Talvez a filosofia Ada seja mais um avanço do que
a linguagem Ada, pois é a filosofia da modularização, dos tipos de dados abstratos e da
estruturação hierárquica. Talvez a Ada seja rica demais, o produto natural do processo
pelo qual os requisitos foram estabelecidos em seu design. Isso não é fatal, pois os
vocabulários de trabalho de subconjunto podem resolver o problema de aprendizado, e os
avanços de hardware nos darão o MIPS barato para pagar os custos de compilação. O
avanço na estruturação de sistemas de software é, de fato, um uso muito bom para o
aumento de MIPS que nossos dólares comprarão. Os sistemas operacionais, criticados
veementemente na década de 1960 por seus custos de memória e ciclo, provaram ser uma
excelente forma de usar alguns dos MIPS e bytes de memória baratos do último aumento
de hardware.
No entanto, a Ada não será a bala de prata que matará o monstro da produtividade do
software. Afinal de contas, ela é apenas mais uma linguagem de alto nível, e a maior
vantagem de tais linguagens veio da primeira transição, das complexidades acidentais da
máquina para a declaração mais abstrata de soluções passo a passo. Uma vez que esses
acidentes tenham sido removidos, os restantes são menores, e o retorno de sua remoção
certamente será menor.
Prevejo que, daqui a uma década, quando a eficácia do Ada for avaliada, veremos que
ele fez uma diferença substancial, mas não por causa de nenhum recurso específico da
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 8

linguagem, nem mesmo por causa de todos eles combinados. Tampouco o novo Ada
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 9

O ambiente do Ada provou ser a causa dos aprimoramentos. A maior contribuição do

Ada será o fato de que a mudança para ele ocasionou o treinamento de programadores em
técnicas modernas de design de software.

Programação orientada a objetos. Muitos estudantes da arte têm mais esperança na

programação orientada a objetos do que em qualquer outro modismo técnico da época.3
Estou entre eles. Mark Sherman, de Dartmouth, observa que devemos ter o cuidado de
distinguir duas ideias distintas que levam esse nome: tipos de dados abstratos e tipos
hierárquicos, também chamados de classes. O conceito de tipo de dados abstrato é que o
tipo de um objeto deve ser definido por um nome, um conjunto de valores adequados e
um conjunto de operações adequadas, em vez de sua estrutura de armazenamento, que
deve estar oculta. Exemplos são os pacotes da Ada (com tipos privados) ou os módulos
do Modula.
Os tipos hierárquicos, como as classes do Simula-67, permitem a definição de
interfaces gerais que podem ser mais refinadas com o fornecimento de tipos
subordinados. Os dois conceitos são ortogonais - pode haver hierarquias sem ocultação e
ocultação sem hierarquias. Ambos os conceitos representam avanços reais na arte de criar
software.
Cada um deles remove mais uma dificuldade acidental do processo, permitindo que o
designer expresse a essência de seu design sem precisar expressar grandes quantidades de
material sintático que não acrescentam nenhum novo conteúdo de informações. Tanto
para os tipos abstratos quanto para os tipos hierárquicos, o resultado é remover um tipo
de dificuldade acidental de ordem superior e permitir uma expressão de ordem superior
do design.
No entanto, esses avanços não podem fazer mais do que remover todas as
dificuldades acidentais da expressão do design. A complexidade do projeto em si é
essencial, e esses ataques não alteram em nada esse aspecto. A programação orientada a
objetos só pode proporcionar um ganho de ordem de grandeza se a vegetação rasteira
desnecessária da especificação de tipos que permanece hoje em nossa linguagem de
programação for responsável por nove décimos do trabalho envolvido no projeto de um
produto de programa. Eu duvido disso.

Inteligência artificial. Muitas pessoas esperam que os avanços na inteligência artificial

ofereçam a descoberta revolucionária que proporcionará ganhos de ordem de magnitude
na produtividade e na qualidade do software.4 Eu não espero. Para entender o motivo,
precisamos dissecar o que significa "inteligência artificial" e depois ver como ela se
aplica.

O Parnaso esclareceu o caos terminológico:

Duas definições bastante diferentes de IA são de uso comum atualmente. IA-1: O

uso de computadores para resolver problemas que antes só podiam ser resolvidos
com a aplicação da inteligência humana. IA-2: O uso de um conjunto específico de
técnicas de programação conhecido como programação heurística ou baseada em
regras. Nessa abordagem, especialistas humanos são estudados para determinar
quais heurísticas ou regras de ouro são usadas na solução de problemas. ......
O programa é projetado para resolver um problema da maneira que os humanos
parecem resolver.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 10

3 Booch, G., "Object-oriented design", em Software Engineering with Ada. Menlo Park, Califórnia:
Benjamin Cummings, 1983.
4 Mostow, J., ed., Special Issue on Artifical Intelligence and Software Engineering, IEEE Trans. on SE, 11,

11 (nov. 1985).
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 11

A primeira definição tem um significado deslizante. Algo pode se encaixar na

definição de AI-1
hoje, mas, quando virmos como o programa funciona e entendermos o problema, não
pensaremos mais nele como IA....Infelizmente,não consigo identificar um corpo de
tecnologia
................................................A maior parte do trabalho é específica para cada
problema, e alguns deles são exclusivos desse campo.
abstração ou criatividade é necessário para ver como transferi-lo.5

Concordo plenamente com essa crítica. As técnicas usadas para o reconhecimento de

fala parecem ter pouco em comum com as usadas para o reconhecimento de imagens, e
ambas são diferentes das usadas em sistemas especializados. Tenho dificuldade em ver
como o reconhecimento de imagens, por exemplo, fará alguma diferença significativa na
prática de programação. O mesmo acontece com o reconhecimento de fala. O mais difícil
na criação de software é decidir o que dizer, não dizer. Nenhuma facilitação da expressão
pode proporcionar mais do que ganhos marginais.
A tecnologia de sistemas especializados, AI-2, merece uma seção própria.

Sistemas especializados. A parte mais avançada da arte da inteligência artificial, e a mais

amplamente aplicada, é a tecnologia de criação de sistemas especializados. Muitos
cientistas de software estão trabalhando arduamente para aplicar essa tecnologia ao
ambiente de criação de software.6 Qual é o conceito e quais são as perspectivas?
Um sistema especializado é um programa que contém um mecanismo de inferência
generalizado e uma base de regras, projetado para receber dados de entrada e suposições
e explorar as consequências lógicas por meio das inferências derivadas da base de regras,
produzindo conclusões e conselhos e oferecendo a explicação de seus resultados ao
refazer o raciocínio para o usuário. Em geral, os mecanismos de inferência podem lidar
com dados e regras difusos ou probabilísticos, além da lógica puramente determinística.
Esses sistemas oferecem algumas vantagens claras em relação aos algoritmos
programados para chegar às mesmas soluções para os mesmos problemas:
• A tecnologia do mecanismo de inferência é desenvolvida de forma independente do
aplicativo e, em seguida, aplicada a muitos usos. É possível justificar um esforço muito
maior nos mecanismos de inferência. De fato, essa tecnologia está bem avançada.
• As partes mutáveis dos materiais específicos do aplicativo são codificadas na base de
regras de maneira uniforme, e são fornecidas ferramentas para desenvolver, alterar,
testar e documentar a base de regras. Isso regulariza grande parte da complexidade do
próprio aplicativo.

Edward Feigenbaum diz que o poder desses sistemas não vem de mecanismos de
inferência cada vez mais sofisticados, mas sim de bases de conhecimento cada vez mais
ricas que refletem o mundo real com mais precisão. Acredito que o avanço mais
importante oferecido pela tecnologia é a separação da complexidade do aplicativo do
próprio programa.
Como isso pode ser aplicado à tarefa de software? De várias maneiras: sugerindo
regras de interface, aconselhando sobre estratégias de teste, lembrando frequências de
tipos de bits, oferecendo dicas de otimização etc.

5Parnas , D.L., "Software aspects of strategic defense systems", Communications of the ACM, 28, 12 (Dez.,
1985), pp. 1326-1335. Também em American Scientist, 73, 5 (setembro-outubro de 1985), pp. 432-440.
6 Balzer, R., "A 15-year perspective on automatic programming" (Uma perspectiva de 15 anos sobre
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 12

programação automática), em Mostow, op. cit.

F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 13

Considere um consultor de testes imaginário, por exemplo. Em sua forma mais

rudimentar, o sistema de diagnóstico especializado é muito parecido com uma lista de
verificação do piloto, oferecendo fundamentalmente sugestões sobre possíveis causas de
dificuldades. À medida que a base de regras é desenvolvida, as sugestões se tornam mais
específicas, levando em conta de forma mais sofisticada os sintomas de problemas
relatados. É possível visualizar um assistente de depuração que oferece sugestões muito
generalizadas no início, mas que, à medida que mais e mais estrutura do sistema é
incorporada à base de regras, torna-se cada vez mais específico nas hipóteses que gera e
nos testes que recomenda. Esse sistema especializado pode se afastar radicalmente dos
convencionais, pois sua base de regras provavelmente deve ser modularizada
hierarquicamente da mesma forma que o produto de software correspondente, de modo
que, à medida que o produto é modificado modularmente, a base de regras de diagnóstico
também pode ser modificada modularmente.
O trabalho necessário para gerar as regras de diagnóstico é um trabalho que terá de
ser feito de qualquer forma ao gerar o conjunto de casos de teste para os módulos e para o
sistema. Se for feito de forma adequadamente geral, com uma estrutura uniforme para as
regras e um bom mecanismo de inferência disponível, ele poderá, na verdade, reduzir o
trabalho total de geração de casos de teste de introdução, além de ajudar nos testes de
manutenção e modificação ao longo da vida. Da mesma forma, podemos postular outros
consultores, provavelmente muitos deles, e provavelmente simples, para as outras partes
da tarefa de construção de software.
Muitas dificuldades se interpõem no caminho da realização antecipada de consultores
especializados úteis para o desenvolvedor do programa. Uma parte crucial de nosso
cenário imaginário é o desenvolvimento de maneiras fáceis de passar da especificação da
estrutura do programa para a geração automática ou semiautomática de regras de
diagnóstico. Ainda mais difícil e importante é a tarefa dupla de aquisição de
conhecimento: encontrar especialistas articulados e autoanalíticos que saibam por que
fazem as coisas e desenvolver técnicas eficientes para extrair o que eles sabem e destilá-
lo em bases de regras. O pré-requisito essencial para a criação de um sistema
especializado é ter um especialista.
A contribuição mais poderosa dos sistemas especializados certamente será colocar a
serviço do programador inexperiente a experiência e a sabedoria acumulada dos melhores
programadores. Essa contribuição não é pequena. A lacuna entre a melhor prática de
engenharia de software e a prática média é muito grande - talvez maior do que em
qualquer outra disciplina de engenharia. Uma ferramenta que dissemine as boas práticas
seria importante.

Programação "automática". Por quase 40 anos, as pessoas têm antecipado e escrito

sobre "programação automática", a geração de um programa para resolver um problema a
partir de uma declaração das especificações do problema. Atualmente, algumas pessoas
escrevem como se esperassem que essa tecnologia proporcionasse o próximo avanço.7

O Parnaso dá a entender que o termo é usado por glamour e não por conteúdo
semântico, afirmando,

Em resumo, a programação automática sempre foi um eufemismo para a

programação com uma linguagem de nível mais alto do que a disponível atualmente
para o programador.8

Ele argumenta, em essência, que na maioria dos casos é o método de solução, e não o
problema, cuja especificação deve ser fornecida.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 14

7 Mostow, op. cit.

8Parnaso , 1985, op. cit.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 15

Exceções podem ser encontradas. A técnica de criação de geradores é muito poderosa

e é usada rotineiramente de forma vantajosa em programas de classificação. Alguns
sistemas de integração de equações diferenciais também permitiram a especificação
direta do problema. O sistema avaliava os parâmetros, escolhia em uma biblioteca de
métodos de solução e gerava os programas.
• Essas aplicações têm propriedades muito favoráveis:
• Os problemas são prontamente caracterizados por relativamente poucos parâmetros.
• Há muitos métodos conhecidos de solução para fornecer uma biblioteca de alternativas.
• Uma análise extensa levou a regras explícitas para a seleção de técnicas de solução,
considerando os parâmetros do problema.

É difícil ver como essas técnicas podem ser generalizadas para o mundo mais amplo
do sistema de software comum, onde casos com propriedades tão perfeitas são a exceção.
É difícil até mesmo imaginar como esse avanço na generalização poderia ocorrer.

Programação gráfica. Um dos temas favoritos das dissertações de doutorado em

engenharia de software é a programação gráfica ou visual, a aplicação de gráficos de
computador ao design de software.9 Às vezes, a promessa de tal abordagem é postulada a
partir da analogia com o design de chips VLSI, em que a computação gráfica desempenha
um papel tão frutífero. Às vezes, a abordagem é justificada pela consideração de
fluxogramas como o meio ideal de design de programas e pelo fornecimento de recursos
avançados para construí-los.
Nada ainda convincente, muito menos empolgante, surgiu de tais esforços. Estou
convencido de que nada surgirá.
Em primeiro lugar, como já argumentei em outro lugar, o fluxograma é uma abstração
muito ruim da estrutura do software.10 Na verdade, ele é melhor visto como a tentativa de
Burks, von Neumann e Goldstine de fornecer uma linguagem de controle de alto nível
desesperadamente necessária para o computador proposto. Na forma lamentável, com
várias páginas e caixas de conexão, para a qual o fluxograma foi elaborado hoje, ele
provou ser essencialmente inútil como ferramenta de design - os programadores
desenham fluxogramas depois, e não antes, de escrever os programas que descrevem.
Em segundo lugar, as telas atuais são muito pequenas, em pixels, para mostrar tanto o
escopo quanto a resolução de qualquer diagrama de software detalhado e sério. A
chamada "metáfora da área de trabalho" da estação de trabalho atual é, em vez disso, uma
metáfora de "assento de avião". Qualquer pessoa que já tenha embaralhado um monte de
papéis enquanto estava sentada em uma poltrona entre dois passageiros corpulentos
reconhecerá a diferença: é possível ver apenas algumas coisas ao mesmo tempo. A
verdadeira área de trabalho oferece uma visão geral e acesso aleatório a um grande
número de páginas. Além disso, quando os acessos de criatividade são fortes, sabe-se que
mais de um programador ou escritor abandonou a área de trabalho para ficar em um andar
mais espaçoso. A tecnologia de hardware terá que avançar bastante antes que o escopo de
nossos escopos seja suficiente para a tarefa de design de software.
Mais fundamentalmente, como argumentei acima, o software é muito difícil de
visualizar. Quer façamos um diagrama de fluxo de controle, aninhamento de escopo de
variáveis, referências cruzadas de variáveis, sopro de dados, estruturas de dados
hierárquicas ou o que quer que seja, sentimos apenas uma dimensão do elefante de
software intrincadamente interligado. Se sobrepusermos todos os diagramas gerados
pelas muitas visualizações relevantes, será difícil extrair qualquer visão global. O VLSI

9 Raeder, G., "A survey of current graphical programming techniques", em R. B. Grafton e T. Ichikawa, eds.,
Special Issue on Visual Programming, Computer, 18, 8 (Aug., 1985), pp. 11-25
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 16

10 Brooks 1995, op. cit., capítulo 15.

F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 17

A analogia é fundamentalmente enganosa - um design de chip é um objeto bidimensional

em camadas cuja geometria reflete sua essência. Um sistema de software não é.

Verificação do programa. Grande parte do esforço da programação moderna é dedicada

ao teste e ao reparo de bugs. Será que existe uma solução mágica a ser encontrada
eliminando os erros na fonte, na fase de projeto do sistema? Será que tanto a
produtividade quanto a confiabilidade do produto podem ser radicalmente aprimoradas
seguindo a estratégia profundamente diferente de provar que os projetos estão corretos
antes que o imenso esforço seja investido em sua implementação e teste?
Não acredito que encontraremos a mágica aqui. A verificação de programas é um
conceito muito poderoso e será muito importante para coisas como kernels de sistemas
operacionais seguros. No entanto, a tecnologia não promete economizar trabalho. As
verificações dão tanto trabalho que apenas alguns programas importantes já foram
verificados.
A verificação de programas não significa programas à prova de erros. Também não
há mágica aqui. As provas matemáticas também podem apresentar falhas. Portanto,
embora a verificação possa reduzir a carga de testes de programas, ela não pode eliminá-
la.
Mais seriamente, mesmo a verificação perfeita do programa só pode estabelecer que
um programa atende à sua especificação. A parte mais difícil da tarefa de software é
chegar a uma especificação completa e consistente, e grande parte da essência da criação
de um programa é, de fato, a depuração da especificação.

Ambientes e ferramentas. Quanto mais se pode esperar das crescentes pesquisas sobre
melhores ambientes de programação? A reação instintiva é que os problemas de grande
retorno foram os primeiros a serem atacados e já foram resolvidos: sistemas de arquivos
hierárquicos, formatos de arquivos uniformes para que haja interfaces de programas
uniformes e ferramentas generalizadas. Os editores inteligentes específicos da linguagem
são desenvolvimentos que ainda não são amplamente utilizados na prática, mas o
máximo que eles prometem é a ausência de erros sintáticos e erros semânticos simples.
Talvez o maior ganho ainda a ser obtido no ambiente de programação seja o uso de
sistemas de banco de dados integrados para acompanhar as miríades de detalhes que
devem ser lembrados com precisão pelo programador individual e mantidos atualizados
em um grupo de colaboradores em um único sistema.
Certamente esse trabalho vale a pena e certamente trará alguns frutos em termos de
produtividade e confiabilidade. Mas, por sua própria natureza, o retorno a partir de agora
deve ser marginal.

Estações de trabalho. Que ganhos podem ser esperados para a arte do software com o
aumento rápido e certo da capacidade de potência e memória da estação de trabalho
individual? Bem, quantos MIPS podem ser usados de forma proveitosa? A composição e
a edição de programas e documentos são totalmente compatíveis com as velocidades
atuais. A compilação poderia ter um aumento, mas um fator de 10 na velocidade da
máquina certamente deixaria o tempo de reflexão como a atividade dominante no dia a
dia do programador. De fato, parece ser assim agora.
Estações de trabalho mais potentes são certamente bem-vindas. Não podemos esperar
melhorias mágicas delas.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 18

Ataques promissores à essência conceitual

Embora nenhum avanço tecnológico prometa oferecer os resultados mágicos com os
quais estamos tão familiarizados na área de hardware, há uma abundância de bons
trabalhos em andamento e a promessa de um progresso constante, embora não
espetacular.
Todos os ataques tecnológicos aos acidentes do processo de software são
fundamentalmente limitados pela equação da produtividade:

Tempo da tarefa = ∑ (Frequência)i x (Tempo) i

Se, como acredito, os componentes conceituais da tarefa estão tomando a maior parte
do tempo, então nenhuma atividade nos componentes da tarefa que são meramente a
expressão dos conceitos pode proporcionar grandes ganhos de produtividade.
Portanto, devemos considerar os ataques que abordam a essência do problema do
software, a formulação dessas estruturas conceituais complexas. Felizmente, alguns deles
são muito promissores.

Comprar versus construir. A solução mais radical possível para a construção de

software é não construí-lo de forma alguma.
A cada dia isso se torna mais fácil, pois cada vez mais fornecedores oferecem mais e
melhores produtos de software para uma variedade estonteante de aplicativos. Enquanto
nós, engenheiros de software, trabalhamos na metodologia de produção, a revolução dos
computadores pessoais criou não um, mas vários mercados de massa para software.
Todas as bancas de jornais têm revistas mensais que, classificadas por tipo de máquina,
anunciam e analisam dezenas de produtos a preços que variam de alguns dólares a
algumas centenas de dólares. Fontes mais especializadas oferecem produtos muito
poderosos para a estação de trabalho e outros mercados Unix. Até mesmo pedágios e
ambientes de software podem ser comprados prontos para uso. Em outra ocasião, propus
um mercado para módulos individuais.
Qualquer produto desse tipo é mais barato de comprar do que de construir novamente.
Mesmo com um custo de US$ 100.000, um software comprado custa apenas o mesmo
que um programador-ano. E a entrega é imediata! Imediata, pelo menos para produtos
que realmente existem, produtos cujo desenvolvedor pode indicar um usuário feliz para o
cliente em potencial. Além disso, esses produtos tendem a ser muito mais bem
documentados e com manutenção um pouco melhor do que o software desenvolvido
internamente.
Acredito que o desenvolvimento do mercado de massa seja a tendência de longo
prazo mais profunda na engenharia de software. O custo do software sempre foi o custo
de desenvolvimento, não o custo de replicação. O compartilhamento desse custo, mesmo
entre poucos usuários, reduz radicalmente o custo por usuário. Outra forma de ver isso é
que o uso de n cópias de um sistema de software multiplica efetivamente a produtividade
de seus desenvolvedores por n. Isso é um aprimoramento da produtividade da disciplina e
da nação.
A principal questão, é claro, é a aplicabilidade. Posso usar um pacote disponível no
mercado para realizar minha tarefa? Aqui aconteceu uma coisa surpreendente. Durante as
décadas de 1950 e 1960, estudos e mais estudos mostraram que os usuários não usariam
pacotes prontos para folha de pagamento, controle de estoque, contas a receber, etc. Os
requisitos eram muito especializados, a variação caso a caso era muito alta. Os requisitos
eram muito especializados, a variação de caso a caso era muito alta. Na década de 1980,
encontramos esses pacotes em alta demanda e uso generalizado. O que mudou?
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 19

Na verdade, não são os pacotes. Eles podem ser um pouco mais generalizados e um
pouco mais personalizáveis do que antigamente, mas não muito. Os aplicativos também
não são bem assim. Se
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 20

De qualquer forma, as necessidades comerciais e científicas de hoje são mais diversas e

mais complicadas do que as de 20 anos atrás.
A grande mudança ocorreu na relação entre o custo do hardware e do software. O
comprador de uma máquina de US$ 2 milhões em 1960 achava que poderia pagar US$
250.000 a mais por um programa de folha de pagamento personalizado, que se adaptasse
facilmente e sem interrupções ao ambiente social hostil ao computador. Hoje em dia, os
compradores de máquinas de escritório de US$ 50.000 não podem pagar por programas
personalizados de folha de pagamento; portanto, eles adaptam seus procedimentos de
folha de pagamento aos pacotes disponíveis. Os computadores são agora tão comuns, se
não tão amados, que as adaptações são aceitas como algo natural.
Há exceções drásticas ao meu argumento de que a generalização dos pacotes de
software mudou pouco ao longo dos anos: planilhas eletrônicas e sistemas simples de
banco de dados. Essas ferramentas poderosas, tão óbvias em retrospecto e, ainda assim,
surgidas tão tardiamente, prestam-se a uma infinidade de usos, alguns bem pouco
ortodoxos. Atualmente, há muitos artigos e até livros sobre como lidar com tarefas
inesperadas com a planilha eletrônica. Um grande número de aplicativos que antes eram
escritos como programas personalizados em Cobol ou Report Program Generator agora
são feitos rotineiramente com essas ferramentas.
Atualmente, muitos usuários operam seus próprios computadores diariamente em
aplicativos variados sem nunca escrever um programa. Na verdade, muitos desses
usuários não podem escrever novos programas para suas máquinas, mas, mesmo assim,
são hábeis em resolver novos problemas com elas.
Acredito que a estratégia de produtividade de software mais poderosa para as
organizações humanas hoje em dia é equipar os trabalhadores intelectuais ingênuos na
linha de fogo com computadores pessoais e bons programas generalizados de escrita,
desenho, arquivos e planilhas, e deixá-los à vontade. A mesma estratégia, com recursos
simples de programação, também funcionará para centenas de cientistas de laboratório.

Refinamento de requisitos e prototipagem rápida. A parte mais difícil da criação de

um sistema de software é decidir exatamente o que construir. Nenhuma outra parte do
trabalho conceitual é tão difícil quanto estabelecer os requisitos técnicos detalhados,
incluindo todas as interfaces com pessoas, máquinas e outros sistemas de software.
Nenhuma outra parte do trabalho prejudica tanto o sistema resultante se for feita de forma
errada. Nenhuma outra parte é mais difícil de ser corrigida posteriormente.
Portanto, a função mais importante que os criadores de software desempenham para
seus clientes é a extração e o refinamento iterativos dos requisitos do produto. A verdade
é que os clientes não sabem o que querem. Geralmente, eles não sabem quais perguntas
devem ser respondidas e quase nunca pensaram no problema com os detalhes que devem
ser especificados. Até mesmo a resposta simples - "Fazer com que o novo sistema de
software funcione como nosso antigo sistema manual de processamento de informações"
-é, de fato, simples demais. Os clientes nunca querem exatamente isso. Além disso, os
sistemas de software complexos são coisas que agem, que se movem, que funcionam. A
dinâmica dessa ação é difícil de imaginar. Portanto, ao planejar qualquer atividade de
software, é necessário permitir uma extensa iteração entre o cliente e o designer como
parte da definição do sistema.
Eu daria um passo além e afirmaria que é realmente impossível para os clientes,
mesmo aqueles que trabalham com engenheiros de software, especificar de forma
completa, precisa e correta os requisitos exatos de um produto de software moderno antes
de terem construído e testado algumas versões do produto que estão especificando.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 21

Portanto, um dos esforços tecnológicos atuais mais promissores, e que ataca a

essência, e não os acidentes, do problema de software, é o desenvolvimento de
abordagens e ferramentas para a prototipagem rápida de sistemas como parte da
especificação iterativa de requisitos.
Um protótipo de sistema de software é aquele que simula as interfaces importantes e
executa as principais funções do sistema pretendido, embora não esteja necessariamente
limitado pelas mesmas restrições de velocidade, tamanho ou custo do hardware. Em
geral, os protótipos executam as principais tarefas do aplicativo, mas não tentam lidar
com as exceções, responder corretamente a entradas inválidas, abortar de forma limpa
etc. O objetivo do protótipo é tornar real a estrutura conceitual especificada, para que o
cliente possa testá-la quanto à consistência e à usabilidade
Grande parte dos procedimentos atuais de aquisição de software baseia-se no
pressuposto de que é possível especificar um sistema satisfatório com antecedência, obter
propostas para sua construção, mandar construí-lo e instalá-lo. Acho que essa suposição é
fundamentalmente errada e que muitos problemas de aquisição de software decorrem
dessa falácia. Portanto, eles não podem ser corrigidos sem uma revisão fundamental, que
preveja o desenvolvimento iterativo e a especificação de protótipos e produtos.

Desenvolvimento incremental - desenvolver, e não criar, software. Ainda me lembro

da sacudida que senti em 1958 quando ouvi pela primeira vez um amigo falar sobre criar
um programa, em vez de escrever um. Em um piscar de olhos, ele ampliou toda a minha
visão do processo de software. A mudança de metáfora foi poderosa e precisa. Hoje,
entendemos como a construção de software é semelhante a outros processos de
construção e usamos livremente outros elementos da metáfora, como especificações,
montagem de componentes e andaimes.
A metáfora do edifício perdeu sua utilidade. É hora de mudar novamente. Se, como
acredito, as estruturas conceituais que construímos hoje são muito complicadas para
serem especificadas com precisão antecipadamente e muito complexas para serem
construídas sem falhas, então precisamos adotar uma abordagem radicalmente diferente.
Vamos nos voltar para a natureza e estudar a complexidade dos seres vivos, em vez
de apenas as obras mortas do homem. Aqui encontramos construções cujas
complexidades nos deixam maravilhados. O cérebro, por si só, é intrincado além do
mapeamento, poderoso além da imitação, rico em diversidade, autoprotegido e
autorrenovável. O segredo é que ele é cultivado, não construído.
O mesmo deve acontecer com nossos sistemas de software. Há alguns anos, Harlan
Mills propôs que qualquer sistema de software deveria ser desenvolvido por meio de
desenvolvimento incremental.11 Ou seja, primeiro o sistema deve ser executado, mesmo
que não faça nada de útil, exceto chamar o conjunto adequado de subprogramas fictícios.
Em seguida, pouco a pouco, ele é aperfeiçoado, com os subprogramas, por sua vez, sendo
desenvolvidos em ações ou chamadas para stubs vazios no nível abaixo.
Tenho visto os resultados mais dramáticos desde que comecei a insistir nessa técnica
com os criadores de projetos em minha aula de laboratório de engenharia de software.
Nada na última década mudou tão radicalmente minha própria prática ou sua eficácia. A
abordagem exige um projeto top-down, pois é um crescimento top-down do software. Ela
permite fácil retrocesso. Ela se presta a protótipos iniciais. Cada função adicionada e cada
nova provisão para dados ou circunstâncias mais complexas crescem organicamente a
partir do que já existe.

11 Mills, H. D., "Top-down programming in large systems", Debugging Techniques in Large Systems, R.
Rustin, ed., Englewood Cliffs, N.J., Prentice-Hall, 1971.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 22

Os efeitos sobre o moral são surpreendentes. O entusiasmo aumenta quando há um

sistema em funcionamento, mesmo que seja um sistema simples. Os esforços redobram
quando a primeira imagem de um novo sistema de software gráfico aparece na tela,
mesmo que seja apenas um retângulo. Sempre se tem, em cada etapa do processo, um
sistema em funcionamento. Descobri que as equipes podem desenvolver entidades muito
mais complexas em quatro meses do que podem construir.
Os mesmos benefícios podem ser obtidos em projetos grandes e pequenos.12

Grandes designers. A questão central de como aprimorar a arte do software está

centrada, como sempre, nas pessoas.
Podemos obter bons designs seguindo boas práticas em vez de práticas ruins. As boas
práticas de design podem ser ensinadas. Os programadores estão entre a parte mais
inteligente da população, portanto, podem aprender boas práticas. Portanto, um grande
impulso nos Estados Unidos é a promulgação de boas práticas modernas. Novos
currículos, nova literatura, novas organizações, como o Software Engineering Institute,
foram criados para elevar o nível de nossa prática de ruim para boa. Isso é totalmente
adequado.
No entanto, não acredito que possamos dar o próximo passo para cima da mesma
forma. Embora a diferença entre designs conceituais ruins e bons possa estar na solidez
do método de design, a diferença entre designs bons e excelentes certamente não está.
Grandes projetos vêm de grandes designers. A construção de software é um processo
criativo. Uma metodologia sólida pode capacitar e liberar a mente criativa, mas não pode
incendiar ou inspirar a mente pesada.
As diferenças não são pequenas - é como Salieri e Mozart. Estudo após estudo mostra
que os melhores designers produzem estruturas mais rápidas, menores, mais simples,
mais limpas e produzidas com menos esforço. As diferenças entre os melhores e os
medianos chegam a uma ordem de grandeza.
Uma pequena retrospectiva mostra que, embora muitos sistemas de software bons e
úteis tenham sido projetados por comitês e construídos por projetos de várias partes, os
sistemas de software que entusiasmaram os fãs apaixonados são aqueles que são produtos
de uma ou poucas mentes projetistas, grandes projetistas. Considere o Unix, APL, Pascal,
Modula, a interface Smalltalk e até mesmo o Fortran; e compare com Cobol, PL/I, Algol,
MVS/370 e MS-DOS (fig. 1)

Sim Não
Unix Cobol
APL PL/1
Pascal Algol
Módulos MVS/370
Smalltalk MS-DOS
Fortran
Fig. 1 Produtos interessantes

Portanto, embora eu apoie firmemente os esforços de transferência de tecnologia e

desenvolvimento de currículo que estão em andamento, acho que o esforço individual
mais importante que podemos fazer é desenvolver maneiras de formar grandes designers.

12 Boehm, B. W., "A spiral model of software development and enhancement", Computer, 20, 5 (May,
1985), pp. 43-57.
F. Brooks: No Silver Bullet-Essence and accident in software engineering (1986) 23

Nenhuma organização de software pode ignorar esse desafio. Bons gerentes, por mais
escassos que sejam, não são mais raros do que bons designers. Tanto os grandes
designers quanto os grandes gerentes são muito raros. A maioria das organizações
despende um esforço considerável para encontrar e cultivar os candidatos a gerentes; não
conheço nenhuma que despenda o mesmo esforço para encontrar e desenvolver os
grandes designers, dos quais a excelência técnica dos produtos dependerá em última
instância.
Minha primeira proposta é que cada organização de software deve determinar e
proclamar que os grandes designers são tão importantes para seu sucesso quanto os
grandes gerentes, e que se pode esperar que eles sejam nutridos e recompensados da
mesma forma. Não apenas o salário, mas também os privilégios do reconhecimento -
tamanho do escritório, mobília, equipamento técnico pessoal, fundos para viagens, apoio
à equipe - devem ser totalmente equivalentes.
Como desenvolver grandes designers? O espaço não permite uma discussão longa,
mas algumas etapas são óbvias:
• Identifique sistematicamente os melhores designers o mais cedo possível. Os melhores
geralmente não são os mais experientes.
• Designe um mentor de carreira para ser responsável pelo desenvolvimento do cliente
potencial e mantenha um arquivo de carreira cuidadoso.
• Elaborar e manter um plano de desenvolvimento de carreira para cada cliente em
potencial, incluindo estágios cuidadosamente selecionados com os melhores designers,
episódios de educação formal avançada e cursos de curta duração, todos intercalados
com design individual e atribuições de liderança técnica.
• Oferecer oportunidades para que os designers em crescimento interajam e estimulem uns
aos outros.
■