Falhas de software program evitáveis ​​custam trilhões

Conversar com Robert N. Charette pode ser muito deprimente. Charette, que tem escrito sobre falhas de software program para esta revista nos últimos 20 anos, é um renomado analista de risco e especialista em sistemas que, ao longo de uma carreira de 50 anos, viu mais do que a sua cota de pensamento delirante entre profissionais de TI, funcionários do governo e executivos corporativos, antes, durante e depois de falhas massivas de software program.

Em 2005 “Por que o software program falha,” em Espectro IEEEum artigo seminal que documenta as causas por trás de falhas de software program em grande escala, Charette observou: “A maior tragédia é que falha de software program é na maior parte previsível e evitável. Infelizmente, a maioria das organizações não vê a prevenção de falhas como uma questão urgente, embora essa visão corra o risco de prejudicar a organização e talvez até de destruí-la. Compreender por que razão esta atitude persiste não é apenas um exercício académico; tem implicações tremendas para os negócios e a sociedade.”

Duas décadas e vários trilhões de dólares desperdiçados depois, ele descobre que as pessoas estão cometendo os mesmos erros. Eles afirmam que seu projeto é único, portanto as lições anteriores não se aplicam. Eles subestimam a complexidade. Os gerentes saem com orçamentos e prazos irrealistas. O teste é inadequado ou ignorado completamente. As promessas dos fornecedores que são boas demais para ser verdade são aceitas pelo valor nominal. Abordagens de desenvolvimento mais recentes, como DevOps ou os copilotos de IA são implementados sem a formação adequada ou a mudança organizacional necessária para tirar o máximo partido deles.

O que é pior, os enormes impactos destes erros nos utilizadores finais não são totalmente contabilizados. Quando o governo canadense Sistema de contracheque Phoenix inicialmente falharam, por exemplo, os desenvolvedores encobriram o sofrimento financeiro e emocional prolongado infligido a dezenas de milhares de funcionários que recebiam contracheques errados; os problemas persistem hoje, nove anos depois. Talvez seja porque, como Charette me disse recentemente, Projeto de TI os gerentes não têm requisitos de licenciamento profissional e raramente, ou nunca, são legalmente responsabilizados por desastres de software program.

Enquanto dispositivos médicos pode parecer muito longe de ser gigante Projetos de TIeles têm algumas coisas em comum. Como o editor de projetos especiais, Stephen Cass, descobriu no artigo deste mês Os dadoso A Meals and Drug Administration dos EUA recorda em média, 20 dispositivos médicos por mês devido a problemas de software program.

“O software program é tão importante quanto a eletricidade. Nunca toleraríamos que a eletricidade acabasse dia sim, dia não, mas com certeza não temos problemas em ter AWS desça.” —Robert N. Charette

Tal como os projetos de TI, os dispositivos médicos enfrentam desafios fundamentais impostos pela complexidade do software program. O que significa que os testes, embora rigorosos e regulamentados no domínio médico, não podem cobrir todos os cenários ou todas as linhas de código. A principal diferença entre dispositivos médicos que falharam e projetos de TI que falharam é que uma enorme quantidade de responsabilidade atribui ao primeiro.

“Quando você cria software program para dispositivos médicos, há muito mais padrões que precisam ser atendidos e muito mais preocupação com as consequências de falhas”, observa Charette. “Porque quando essas coisas não funcionam, há leis de responsabilidade civil disponíveis, o que significa que os fabricantes estão em risco. É muito mais difícil abrir um caso e vencer quando você está falando sobre um produto eletrônico folha de pagamento sistema.”

Quer seja um falha de software program seja hiperlocal, como quando um dispositivo médico falha dentro do seu corpo, ou se espalha por uma região inteira, como quando o sistema de emissão de bilhetes de uma companhia aérea falha, as organizações precisam investigar as causas profundas e aplicar essas lições ao próximo dispositivo ou projeto de TI se quiserem impedir que a história se repita.

“O software program é tão importante quanto a eletricidade”, diz Charette. “Nunca toleraríamos que a eletricidade acabasse dia sim, dia não, mas com certeza não temos nenhum problema em aceitar a queda da AWS ou das empresas de telecomunicações ou bancos saindo.” Ele solta um suspiro pesado digno do Bisonho de AA Milne. “As pessoas meio que encolhem os ombros.”