Não há Bala de Prata para o Desenvolvimento de Software
“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity” — Frederick P. Brooks, Jr.
Em 1986 fora publicado um dos grandes clássicos da Engenharia de Software, o artigo “No Silver Bullet — Essence and Accident in Software Engineering” (Não há bala de prata — Essência e Acidente na Engenharia de Software) por Frederick P. Brooks, cuja principal contribuição é refletida pela frase acima.
Uma tradução livre para essa frase poderia ser: “Não há nenhuma metodologia individual de desenvolvimento, em tecnologia ou técnicas de gestão, que por si só prometa um incremento ainda que de uma ordem de grandeza dentro de uma década em produtividade, em confiabilidade, em simplicidade”. Ou seja, não há uma bala de prata que sozinha resolva os problemas do Software.
Neste artigo, o autor faz uma brilhante — e também estranha — analogia entre o Software e o Lobisomem, alegando que estes seres se transformam, inesperadamente, de coisas familiares à seres horripilantes. A diferença é que para o Lobisomem, basta uma bala de prata para se resolver o problema. Com relação ao Software, os horrores seriam os prazos perdidos, orçamentos estourados e produtos com falhas, só que diferentemente do Lobisomem, não há uma única bala de prata que resolva esses problemas.
Abaixo um breve resumo dos aspectos tratados pelo autor que, em sua argumentação, divide os problemas envoltos ao desenvolvimento de Software em dois: acidentais e essenciais. Os problemas acidentais dizem respeito aos problemas relacionados com a fabricação do Software e estão quase sempre associados a limitações tecnológicas. Já os problemas essenciais são aqueles inerentes a sua própria natureza, e como veremos, são a real causa de sua complexidade.
Se analisarmos bem, muitos dos problemas acidentais têm sido resolvidos ao longo dos anos. As restrições de memória e processamento de hoje nem se comparam àquelas de 30 anos atrás, sem contar que hoje desenvolvemos num ambiente multitarefa — imagine só você programando sua aplicação para um sistema de processamento em batch. Outra coisa que têm contribuído bastante para a eliminação dos problemas acidentais são as linguagens de alto nível, que têm evoluído bastante e cada vez mais contribuem para a produtividade do desenvolvimento, confiabilidade e simplicidade do Software. Sabemos que estas linguagens não possuem a mesma performance de linguagens de mais baixo nível, como por exemplo C; entretanto, conforme os processadores evoluem, vale a pena se trocar alguns ciclos por essas melhorias.
Mas por que porque o desenvolvimento continua tão complexo mesmo com tantas melhorias,?
R: Porque os seus principais desafios não são os acidentais, mas sim os essenciais.
Como já dito, os problemas essenciais dizem respeito a características que são inerentes somente ao Software. Eles referem-se aos desafios da criação de um modelo conceitual para os sistemas. Neste sentido, Brooks elenca quatro desafios referentes ao Software que dificilmente são encontrados em outras ciências.
- Complexidade: a qual se refere ao fato de que no desenvolvimento Software não existem dois elementos repetidos ou idênticos, quando existem eles são transformados em uma coisa só na forma de funções. Essa característica é um grande desafio na hora de escalar o Software para desafios maiores, uma vez que não basta o uso dos mesmos componentes em tamanho maior, como muitas vezes acontece com o Hardware, construções, automóveis e outras máquinas, onde os elementos repetidos superabundam. Dessa forma, não crescimento linear para o Software.
- Conformidade: Não é só o Software que sofre com os problemas de complexidade, a física por exemplo também sofre, no entanto, diferentemente desta última o Software não possui leis imutáveis as quais se possa agarrar. 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. Como diz o autor, as vezes não é nem por necessidade, mas simplesmente porque os padrões são desenvolvidos por pessoas e não por Deus, como no caso da física e as leis da natureza.
- Alterabilidade: O Software é constantemente sujeito a pressões por mudança. Isso se deve a sua característica abstrata que lhe confere a impressão de que mudanças são fáceis de se fazer, muito diferente daquilo que ocorre com os produtos manufaturados do mundo físico. Para tal, basta se comparar a quantidade de recalls que acontecem no setor automobilístico com a quantidade de atualizações na indústria de Software. Esta característica é em parte benéfica por permitir uma ‘rápida’ evolução dos sistemas, entretanto, paga-se o preço para tal.
- Invisibilidade: Essa é talvez a característica mais intuitiva, acredito que todos já ouviram aquela famosa expressão de que o Software é aquilo que se xinga. Pois é, 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. Esta característica representa um grande desafio para o projeto de sistemas e a sua representação para terceiros.
Considerando-se essas características de forte cunho abstrato, não é difícil de se concluir que dificilmente existirá uma única solução que alavanque a produtividade, a confiabilidade e a simplicidade do Software, assim como por exemplo foram os transistores para a eletrônica.
Entretanto, dada esta extensa discussão, onde a segurança se encaixa? É preciso entender que a segurança é também um atributo do Software, assim como usabilidade, performance, simplicidade, entre outros. Portanto, os desafios acima citados impactam a segurança de igual forma, uma vez que é igualmente difícil de se implementar segurança à algo que precisa se adaptar a tudo, que vive sendo alterado e é de difícil representação.
Em vista de tudo isso, o primeiro ponto é que os problemas de segurança no Software decorrem primeiramente de sua própria complexidade inerente. É importante compreendermos isso antes de atirarmos nossas pedras em quem quer que seja. A evolução da segurança no Software continuará a ser gradual e fruto de um conjunto de atividades e processos. Se você ainda espera uma solução mágica para esse problema, esqueça, pois isso não vai acontecer.
Esta postagem pertence a série “Desenvolvimento vs Segurança“. Por mais que a complexidade do Software contribua bastante para os problemas de segurança, ainda há outros problemas que tornam esta situação muito pior, acompanhe as próximas postagens desta série para aprender mais.
Originally published at iopub.org on August 24, 2016.
