The Coming Software Apocalypse

Meu amigo Thomas Rose me mandou este artigo:

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.

Bad software example

Very bad software. With detailed explanation of the reasons it is so bad: Microsoft Word.

Fim dos ERPs? ou Fim do Software?

Artigo na Forbes atacando a SAP: For Enterprise IT, Time To Move Beyond SAP.

O ataque não é à SAP, que percebe como líder de mercado, mas a ERPs em geral, incluindo Oracle e outros. O que é incorreto, ele deveria analisar o mercado de ERP. E aí teria uma perspectiva diferente. Por exemplo uma coisa que ele não menciona é que os ERPs não são estáticos, evoluem. Tem muito ERP de nicho. E os grandes, SAP, Oracle, tem versões para nichos. Outra coisa do mercado de ERPs é que estão saindo soluções para cloud, ainda no começo, que parecem competir com ERPs mas na verdade são uma outra forma de vender o ERP. O mercado evolui.

Indo mais fundo na análise, o que ele diz é que quando as empresas adotam uma solução empacotada, perdem a criatividade que software permite. É o que este blog diz. Software pronto não é mais software. Perde-se a programabilidade, portanto a oportunidade de ser diferente. Nisto ele tem razão. Mas cuidado, em que uma empresa pode ser diferente e ganhar competitividade com a Folha de Pagamento, por exemplo? Talvez seja melhor ter um ERP padrão, igual ao do concorrente, para coisas administrativas burocráticas e repetitivas. E deixar a criatividade para o core business. Este é o ponto.

Há poucas empresas pensando em TI como oportunidade criativa de se diferenciar do concorrente. Ao contrário, procuram colocar ERP em todas as áreas possíveis da empresa. Transferem a criatividade para por exemplo BI, que é uma ferramenta pronta. Talvez os bancos usem TI de forma criativa, ou as empresas de cartão de crédito. Eles desenvolvem seu software, compram pouco software pronto.

O artigo fala da rigidez do SAP. Tem razão. Todos os ERPs são mais ou menos rígidos. Mas mesmo os menos rígidos estão longe de serem abertos, programáveis, que aí sim daria espaço para criatividade.

Ir para o cloud faz diferença? Não, o cloud é a infra onde roda o ERP, não muda nada ir para o cloud assim como a terceirização da infra com empresas como Tivit, IBM, Diveo não mudou nada, é só mais barato terceirizar. O usuário nem percebe.

" It’s time to get creative again" diz ele. Concordo mas duvido. Não é indo para o cloud que se fica criativo. É desenvolvendo soluções diferentes. Não vejo muita empresa fazendo isso. Ao contrário, elas vão para o cloud porque a solução no cloud é também um ERP, só que mais barato, ou mais fácil de usar. Observe: se uma empresa adota uma solução no cloud, como Salesforce.com, outra pode adotar também, aí todas adotam e pronto, caímos na mesma situação que ele descreve quando todos adotaram ERP. Sem criatividade, sem diferenciação.