Como não tenho acesso a dados ou fatos concretos, só posso oferecer observações anedóticas recolhidas dos meus últimos 20 anos em TI.
Acredito que exista uma grande diferença entre a maneira como a maioria dos desenvolvedores cria software hoje em comparação com 20 anos atrás. Com o movimento Agile ganhando tanto impulso, principalmente nos últimos 5 a 6 anos, vi uma mudança real de atitudes no local de trabalho. Tanto é assim que a qualidade do que fazemos parece crescer aos trancos e barrancos a cada ano, e a cada projeto à medida que aplicamos as lições que aprendemos de um projeto para outro. Os processos mais enxutos, combinados com o foco no desenvolvimento do primeiro teste, passaram de muito controversos a comuns. Tanto é assim que, para entrar em muitas empresas hoje, se você não se sentir confortável com o Agile, terá sorte se elas não lhe mostrarem a porta.
Então, que impacto isso teve? Antes de tudo, notei que os problemas costumam ser identificados muito mais cedo. Frequentemente, se o problema não parecer muito grande, às vezes ele pode ser suspenso indefinidamente. Em um raro punhado de casos, vi bugs que eram considerados triviais se tornarem problemas sérios quando abordados mais tarde, pois se torna aparente uma questão fundamental que não foi considerada na época. Às vezes, isso pode levar a um ciclo de correção prolongado, e isso pode custar um certo grau, mas esse custo geralmente é medido menos em termos de recursos e, mais frequentemente, em termos do impacto no relacionamento entre cliente e desenvolvedor. Os clientes estão se acostumando com essa maneira de pensar ágil, que gera resultados muito mais rapidamente do que nos velhos tempos, com sprints de desenvolvimento altamente iterativos e rápida recuperação entre solicitações e implementação, eles esperam muito de nós. E, no que diz respeito aos bugs reais, o tempo para consertar um bug diminui com mais frequência devido à existência de um conjunto sólido de testes para dar suporte às mudanças e à capacidade de criar novos testes para fornecer informações e soluções. para os problemas relatados.
Portanto, no geral, parece que o esforço geral para corrigir erros foi, na maioria dos casos, reduzido se houver um conjunto robusto de testes e procedimentos para garantir que o teste continue sendo o foco do que o desenvolvedor faz, mas o custo real em alguns aspectos, mudou em parte, pelo menos da implementação, para outras áreas do negócio, porque, em alguns aspectos, o foco também mudou da oferta e demanda puras para o gerenciamento de relacionamentos.
Outra coisa que se tornou aparente é que nossos instintos intestinais de alguns anos atrás, que sugeriam que ser ágil reduziria nossos ciclos de manutenção, foram provados, tanto em certo quanto em errado. Bem no sentido de que testes sólidos tornaram mais fácil depurar e corrigir nosso código em grande parte e reduzir em geral o número de bugs lançados no código de produção, e errados no sentido de que agora estamos trabalhando mais para evitar a necessidade de manter o código legado, refatorando constantemente o código e aprimorando a arquitetura, para que fique cada vez mais raro o desenvolvimento de novos produtos completamente do zero.
Então, no final, o que isso significa com relação à pergunta do OP? Bem, isso significa que a resposta realmente não é tão cortante e seca quanto pensávamos que fosse. 15 anos atrás, eu provavelmente teria respondido a pergunta como um Sim, mas agora sinto que é mais realista dizer que é realmente muito difícil medir empiricamente, porque a natureza do que fazemos para desenvolver software mudou muito desde quando começamos a nos perguntar a pergunta do OP naquela época. De certa forma, quanto mais avançamos nossas técnicas e habilidades como indústria, mais a questão cresce de um sim definitivo, a um ponto em que suspeito que em um curto número de anos estaremos dizendo que isso não importa quando corrigimos bugs, porque nossos testes e processos serão muito mais robustos, que o tempo das correções será menos orientado pelos esforços para salvar nossos orçamentos e mais por prioridades para satisfazer as necessidades de nossos clientes, e o custo relativo tornam-se virtualmente sem sentido contextualmente.
Mas, como eu disse, isso não é uma evidência suportada por dados, apenas minhas observações dos últimos anos e meu intestino me dizendo que haverá mais sabedoria inovadora por vir que melhorará a maneira como fazemos as coisas.