https://medium.com/the-atlantic/the-coming-software-apocalypse-4ffb43f3b288
ou
https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/
Resposta:
Thomas, detestei este artigo. Ele diz algumas coisas interessantes sobre software. OK.
Mas ele adota o tom de explicar software para leigos, falando em jeitos de programar, formas de falar, hábitos e gírias de programadores. Aí ele conta algumas histórias de terror. E depois entrevista uns pesquisadores que "descobriram" como não se deve fazer software. E a solução que eles encontram é: "não se deve escrever software". Aí no melhor caso descreve uma ferramenta que cria software a partir de especificação. Pequeno problema: esta ferramenta é por sua vez um software. Também sujeito a bugs. Em outros casos descreve ferramentas visuais para ver o que o software faz. Mesmo problema, também são software. E mais um agravante: quem garante que o visual corresponde aos requerimentos? E outro agravante: estas ferramentas iludem fazendo o desenvolvedor pensar que escrever software é uma atividade lúdica de mover caixainhas. Não funciona.
A realidade é que há 2 considerações a fazer quanto a problemas com software:
1. Qualidade. Simplesmente deve-se adotar padrões de qualidade. Fortes. Isto inclui requerimentos bem definidos, testes, testes e mais testes exaustivos, revisão do software, uso de ferramentas boas para desenvolvimento não joguinhos, homologação, responsabilização de quem desenvolve software. Enfim, profissionalizar o desenvolvimento de software.
O que custa caro. Então muitos vão continuar a usar sobrinhos para desenvolver, amadores, programadores recém-formados que custam pouco.
2. Matemática. O artigo é falho ao descrever software como uma atividade exótica e invisível. Nada disso. Software é matemática. Simples assim. Tem sim que escrever um monte de código sem ver o que vai acontecer. É assim que matemática funciona. E pode-se, sim, provar que software faz o que deve fazer. Hoje existem métodos, ferramentas e linguagens que permitem isso.
Finalmente, o exemplo a partir do qual o artigo é construído, o caso da pane no serviço 911, é um péssimo exemplo. Porque não houve êrro de software. Houve êrro de especificação de reuqerimentos. Alguém não informou o número limite, e o programador colocou o número da cabeça dele. O software executou direitinho o que tinha que executar. Quem especificou deveria ter se preocupado com o que acontecerá quando se chegar ao número limite.
Algumas citações do artigo: "Code is too hard to think about". É... verdade... matemática às vezes é hard to think about. Ainda bem que existem matemáticos.
"What made programming so difficult was that it required you to think like a computer". Bull-shit. Não existe "think like a computer". Existem algoritmos, e qualquer ser humano é capaz de imaginar um algoritmo funcionando.
"Why was it so hard to learn to program? The essential problem seemed to be that code was so abstract.": bobagem. Matemática é abstrata, e a gente aprende matemática e aprende a pensar coisas abstratas. Veja, além dos próprios matemáticos, engenheiros, economistas, físicos, etc, etc, etc.
