Este artigo começa fazendo uma comparação entre o temido lobisomem com o

software, onde de um familiar homem, inesperadamente se transforma em um monstro

horripilante e que só uma bala de prata pode acabar com ele. E analogamente, o
software de inocente e simples pode se “transformar” em um produto imperfeito e de
orçamentos estourados, e quando isso acontece também se procura uma bala de prata
para acabar com esses problemas. Mas segundo o autor, não há um avanço
tecnológico que melhore a ordem de magnitude da produtividade, confiabilidade e a
simplicidade e com isso não há nenhuma bala de prata a vista. O artigo vai ter como
objectivo defender que avanços conquistados até hoje e como eles foram promovidos
em cima das questões acidentais do software, e que ganhos no desenvolvimento das
actividades essenciais são muito mais difíceis de serem alcançados. Brooks afirma que
não é o software que avança devagar, mas o progresso do hardware é que rápido e
que não existem paralelos tecnológicos no mundo com a velocidade da inovação em
hardware. Ele acredita que a parte dura da construção do software é a especificação,
design, e os testes dessa construção conceitual e não o trabalho de representar e
testar a fidelidade da representação. Ele analisou algumas propriedades inerentes à
essência dos problemas de desenvolvimento de software, que são: a complexidade,
conformidade, adaptabilidade e invisibilidade. A complexidade exigida para a produção
de um software é muito maior que a de um computador. Uma entidade de software não
é apenas uma repetição dos mesmos elementos, é um aumento no número de
elementos diferentes. Na maioria dos casos, os elementos interagem uns com os
outros não linearmente, e a complexidade do conjunto aumenta muito mais do que
linearmente. Muitos dos problemas clássicos de desenvolvimento de produtos de
software resultam dessa complexidade. Dela surge a dificuldade de comunicação entre
os membros da equipe, o que leva a falhas nos produtos, aos custos excedentes e
atrasos no calendário. Gera também a dificuldade de enumerar todos os possíveis
estados do programa. A complexidade das funções gera dificuldades de invocá-las. E a
complexidade da estrutura gera dificuldades na invocação das funções sem que
ocorram outros erros ocasionais. O Software precisa se adaptar a todo tipo de
interface, sistema ou instituição existente, e se não bastasse, estes supostos padrões
mudam de tempos em tempos de acordo com a moda do momento não pode ser bem
vista porque se não, deixará o sistema obsoleto e fora de mercado. Como não pode
haver conformidade a adaptabilidade ou alterabilidade deixa de existir, porque O
Software é constantemente sujeito a pressões por mudança. Isso se deve a sua
característica abstracta que lhe confere a impressão de que mudanças são fáceis de se
fazer. A evolução é mais lenta mais tem que existir. Mas ele não precisa ser modificado
como um todo, assim que é composto por funções, somente algumas delas podem ser
alteradas de acordo com o que o mercado necessita e na invisibilidade, o Software é
de fato invisível, não é possível representa-lo a partir de formas geométricas ou outras
formas compreendidas pelo senso comum. Podemos ver os limites naturais para a
extrapolação de cada ataque. Da análise das etapas em tecnologia do software que
mais se destacaram no passado conclui-se que o maiores avanços deram melhoras de
produtividade no que concerne a criação dos software, etapas essas que são: a
Linguagens de auto nível, Time-sharing e Ambientes de programação unificados. A
utilização da linguagem de alto nível liberta um programa de muitas das suas
complexidades acidentais. A medida em que a linguagem de alto nível incorpora as
construções que se quer na programação abstracta e evita todos os mais baixos,
elimina todo um nível de complexidades e isso nunca foi inerente ao programa.

A linguagem de alto nível fornece todas as construções que o programador imagina no

programa abstrato. Com certeza, o nível de nosso pensamento sobre estruturas de
dados, tipos de dados e operações está aumentando constantemente, mas sempre
taxa decrescente. E o desenvolvimento do idioma se aproxima cada vez mais
sofisticação dos usuários. Mas, embora ela seja realmente muito importante na
melhora de produtividade, este avanço só vai ter impacto sobre a complexidade
acidental, e não no problema em si. O time-sharing permite que alguém mantenha uma
visão geral da complexidade, embora não tão grande como a traz ida pelas linguagens
de alto nível, mas o custo da interrupção gerada pode levar a uma perda da noção
geral da complexidade do sistema em desenvolvimento. Por isso que uma boa
organização e divisão de tarefas ajudam a preservar a linha de raciocínio da principal
tarefa a ser desenvolvida. Ambientes de programação unificada, atacam as
dificuldades acidentais de usar o programa em conjunto através do fornecimento de
Bibliotecas integradas e formatos de arquivos unificados, que fazem, na prática, ser
possível integrar estruturas conceituais cujo projecto já prévia esta integração, de forma
que não resolveram nenhum problema essencial ao trabalho de construir um sistema
de software. Brooks propôs soluções mágicas para tentar resolver, ou diminuir esses
problemas, entre elas, a Ada e outras linguagens de alto nível que ajuda o
desenvolvedor de softwares a elaborar e produzir novas técnicas de projectar o
sistema. Tem também a orientação a objectos que não resolvem questões
relacionadas à projectos de softwares ou análise, mas resolvem questões acidentais
provendo tipos abstractos de dados e uma hierarquia de tipos. A inteligência artificial
que ajuda o desenvolvimento optimizando o software, mas não seria uma bala de prata
porque não resolve problemas genéricos e ainda requer trabalho e criatividade para
permitir aplicar uma solução a novas questões. A programação automática, que até
hoje não se viu algo que passe uma especificação directamente para código, mas se
existem, tem aplicações muito específicas. Tem também a Verificação de Programas,
Ambientes e Ferramentas e Workstations.