A Entrega Contínua e o Caixão do Software de Qualidade
O recente desastre da CrowdStrike é apenas o último sintoma de uma doença muito maior que assola a indústria de software.
A agilidade, quando aplicada de forma correta, é uma força poderosa para o desenvolvimento de software. No entanto, a busca incessante por entregas rápidas e frequentes, tem levado a um cenário em que a qualidade é sacrificada em nome da velocidade. É como se a indústria de software tivesse se transformado em uma fábrica de fast-food, onde a velocidade prevalece sobre a qualidade.
Lembra da era de ouro dos games? Quando um jogo era lançado, ele era impresso em um cartucho ou gravado em um DVD. Não havia volta, nenhuma correção, nenhum hotfix. Se seu jogo estivesse cheio de bugs ou incompleto, era um desastre financeiro. A pressão para entregar o melhor produto possível era imensa. O resultado? Jogos eram normalmente impecáveis.
Avançando para hoje, estamos na era do lançamento de "acesso antecipado". Jogos, e cada vez mais outros softwares, são lançados inacabados com a promessa de "melhorar depois". A entrega contínua se tornou a desculpa perfeita para um trabalho mal feito. É como se estivéssemos dizendo aos clientes: "Não se preocupe com seu produto não estar pronto agora, vamos terminar eventualmente".
Essa mentalidade está se espalhando como fogo. Não são apenas jogos mais. Infraestrutura crítica, sistemas financeiros, até mesmo dispositivos médicos estão sendo submetidos a essa abordagem imprudente. O incidente da CrowdStrike é um duro lembrete de que quando o software falha, as consequências podem ser catastróficas.
Precisamos voltar ao princípio dos lançamentos formais. O software deve ser lançado apenas quando estiver realmente pronto, com evidências robustas de que está correto —não quando for conveniente. É necessário elevar o padrão de qualidade, e os desenvolvedores devem ser responsabilizados pelo software que produzem.
Podemos aprender muito com outras áreas da engenharia. Pense na engenharia civil, por exemplo. Quando uma ponte é construída, ninguém a abriria ao público antes de estar completamente finalizada e ter passado por rigorosos testes de segurança. No Brasil, a ART (Anotação de Responsabilidade Técnica) exige que os engenheiros assinem seus projetos, assumindo total responsabilidade por sua execução. Um erro pode ter implicações criminais severas. Por que deveríamos esperar menos do software, que cada vez mais se torna um componente vital de nossas vidas?
Sabemos que é possível escrever software que funciona corretamente. Isso ocorre quando as organizações responsáveis são motivadas não pelas forças económicas, mas por pressão regulatória significativa. O problema é que a medida que o software continua a "comer o mundo", mais e mais sistemas críticos passam a ser feitos por indústrias que não enfrentam nenhuma pressão regulatória.
Podemos esperar, então que as coisas vão dar muito errado, e um grande desastre envolvendo a perda de muitas vidas é uma questão de "quando" e não de "se". Aí talvez os desenvolvedores parem de tratar seu trabalho como um beta perpétuo e comecem a tratá-lo como o componente crítico de nossas vidas que ele é.