No Silver Bullet, Tradução Google, Formatado, Word

Não há bala de prata: essência e acidentes de engenharia de software
por Frederick P. Brooks, Jr.

De todos os monstros que preenchem os pesadelos do nosso folclore, nenhum aterroriza mais do que os lobisomens, porque eles se transformam inesperadamente do familiar em horrores. Para estes, busca-se balas de prata que magicamente podem pô-las em repouso.

O projeto de software familiar, pelo menos como visto pelo gerente não técnico, tem algo desse caráter; geralmente é inocente e direto, mas é capaz de se tornar um monstro de cronogramas perdidos, orçamentos inflados e produtos defeituosos. Então, ouvimos gritos desesperados por uma bala de prata - algo para fazer os custos de software caírem tão rapidamente quanto os custos de hardware de computador.

Mas, ao olharmos para o horizonte de uma década, não vemos bala de prata. Não existe um desenvolvimento único, seja na tecnologia ou na técnica de gerenciamento, que, por si só, prometa uma melhoria de ordem de magnitude na produtividade, na confiabilidade, na simplicidade. Neste artigo, tentarei mostrar por que, examinando a natureza do problema de software e as propriedades das balas propostas.

O ceticismo não é pessimismo, no entanto. Embora não vejamos avanços surpreendentes - e, de fato, acredito que isso seja inconsistente com a natureza do software - muitas inovações encorajadoras estão em andamento. Um esforço disciplinado e consistente para desenvolver, propagar e explorar essas inovações deve, de fato, produzir uma melhoria de ordem de grandeza. Não há estrada real, mas há uma estrada.

O primeiro passo para o manejo da doença foi a substituição das teorias demoníacas e teorias do humor pela teoria dos germes. Esse mesmo passo, o começo da esperança, por si só frustrou todas as esperanças de soluções mágicas. Dizia aos trabalhadores que o progresso seria feito passo a passo, com grande esforço, e que um cuidado persistente e incessante teria de ser pago a uma disciplina de limpeza. Assim é com engenharia de software hoje.

Tem que ser difícil? - Dificuldades Essenciais

Não só não há balas de prata agora em vista, a própria natureza do software torna improvável que haja alguma - nenhuma invenção que faça para a produtividade, confiabilidade e simplicidade do software o que a eletrônica, os transistores e a integração em grande escala fizeram. para hardware de computador. Não podemos esperar que vejamos ganhos duplos a cada dois anos.

Primeiro, deve-se observar que a anomalia não é que o progresso do software é tão lento, mas que o progresso do hardware do computador é tão rápido. Nenhuma outra tecnologia desde o início da civilização alcançou seis ordens de magnitude no ganho de preço de desempenho em 30 anos. Em nenhuma outra tecnologia pode-se optar por obter o ganho em melhor desempenho ou em custos reduzidos. Esses ganhos fluem da transformação da fabricação de computadores de uma indústria de montagem para uma indústria de processo.

Segundo, para ver que taxa de progresso pode-se esperar na tecnologia de software, vamos examinar as dificuldades dessa tecnologia. Seguindo Aristóteles, eu os divido em essência, as dificuldades inerentes à natureza do software e os acidentes, as dificuldades que hoje assistem à sua produção, mas não são inerentes.

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 na medida em que tal construção conceitual é a mesma sob muitas representações diferentes. No entanto, é altamente preciso e ricamente detalhado.

Acredito que a parte difícil de construir software seja a especificação, o design e o teste desse constructo conceitual, não o trabalho de representá-lo e testar a fidelidade da representação. Ainda fazemos erros de sintaxe, com certeza; mas eles são confusos em comparação com os erros conceituais na maioria dos sistemas.

Se isso for verdade, a construção de software será sempre difícil. Não há inerentemente nenhuma bala de prata.

Vamos considerar as propriedades inerentes a essa essência irredutível dos sistemas de software modernos: complexidade, conformidade, mutabilidade e invisibilidade.

Complexidade. As entidades de software são mais complexas para seu tamanho do que talvez qualquer outro constructo humano, porque não há duas partes iguais (pelo menos acima do nível de instrução). Se eles são, nós fazemos as duas partes similares em uma sub-rotina - aberta ou fechada. Nesse aspecto, os sistemas de software diferem profundamente de computadores, edifícios ou automóveis, onde elementos repetidos são abundantes.

Os computadores digitais são, eles próprios, mais complexos do que a maioria das coisas que as pessoas constroem: eles têm um grande número de estados. Isso faz com que conceber, descrever e testá-los com força. Os sistemas de software têm mais estados de ordem de grandeza do que os computadores.

Da mesma forma, uma ampliação de uma entidade de software não é apenas uma repetição dos mesmos elementos em tamanhos maiores, é necessariamente um aumento no número de elementos diferentes. Na maioria dos casos, os elementos interagem uns com os outros de alguma 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. Assim, as descrições de uma entidade de software que abstraem sua complexidade geralmente abstraem sua essência. Por três séculos, a matemática e as ciências físicas deram grandes passos construindo modelos simplificados de fenômenos complexos, derivando propriedades dos modelos e verificando essas propriedades por meio de experimentos. Esse paradigma 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 de desenvolvimento de produtos de software derivam dessa complexidade essencial e seu aumento não-linear aumenta com o tamanho. Da complexidade vem a dificuldade de comunicação entre os membros da equipe, o que leva a falhas de produto, custos excedentes, atrasos no cronograma. Da complexidade vem a dificuldade de enumerar, muito menos compreender, todos os estados possíveis do programa, e daí vem a falta de confiabilidade. Da complexidade da função vem a dificuldade de invocar a função, o que torna os programas difíceis de usar. Da complexidade da estrutura vem a dificuldade de estender programas a novas funções sem criar efeitos colaterais. Da complexidade da estrutura, vêm os estados não visualizados que constituem alçapões de segurança.