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.