No tengo acceso a datos o datos concretos, por lo que solo puedo ofrecerle observaciones anecdóticas obtenidas de mis últimos 20 años en TI.
Creo que hay una gran diferencia entre la forma en que la mayoría de los desarrolladores crean software hoy en comparación con hace 20 años. Con el movimiento ágil que ha ganado tanto impulso, particularmente en los últimos 5-6 años, he visto un cambio real en las actitudes en el lugar de trabajo. Tanto es así que la calidad de lo que hacemos parece crecer a pasos agigantados cada año, y con cada proyecto a medida que aplicamos las lecciones que hemos aprendido de un proyecto a otro. Los procesos Leaner combinados con un enfoque en el desarrollo de prueba primero han pasado de ser muy controvertidos a ser comunes. Tanto es así que hoy, si no te sientes cómodo con Agile, entrarás en muchas compañías y tendrás suerte si no te muestran la puerta.
Entonces, ¿qué impacto ha tenido esto? En primer lugar, he notado que los problemas a menudo se identifican mucho antes. A menudo se da el caso de que si el problema no parece ser demasiado grande, a veces se puede suspender indefinidamente. En un puñado de casos, he visto errores que se creían triviales que se convierten en problemas serios cuando se abordan más tarde, ya que se hace evidente un problema fundamental que no se consideró en ese momento. A veces, esto puede conducir a un ciclo de arreglo prolongado, y eso puede ser costoso hasta cierto punto, pero ese costo a menudo se mide menos en términos de recursos y, más a menudo, en términos del impacto en la relación entre el cliente y el desarrollador. Los clientes se están acostumbrando a esta forma ágil de pensar, que les devuelve resultados mucho más rápido que en los viejos tiempos, con sprints de desarrollo altamente iterativos y respuesta rápida entre solicitudes e implementación, por lo que han llegado a esperar mucho de nosotros. Y en lo que respecta a los errores reales, el tiempo para solucionar un error se reduce con mayor frecuencia como resultado de tener un conjunto sólido de pruebas para soportar los cambios, y la capacidad de crear nuevas pruebas para proporcionar información y soluciones a los problemas reportados.
Entonces, en general, parece que el esfuerzo general para corregir errores se ha reducido en la mayoría de los casos si hay un conjunto robusto de pruebas y procedimientos para garantizar que las pruebas sigan siendo el foco de lo que hace el desarrollador, pero el costo real se ha desplazado de alguna manera, al menos en parte, desde la implementación a otras áreas del negocio, porque de alguna manera, el enfoque también se ha desplazado de la oferta y la demanda pura a la gestión de relaciones.
Otra cosa que se ha hecho evidente es que nuestros instintos intestinales de hace unos años, que sugerían que ser ágiles reducirían nuestros ciclos de mantenimiento, han sido probados en cierto grado, tanto correctos como incorrectos. Justo en el sentido de que las pruebas sólidas han hecho que sea más fácil depurar y corregir nuestro código en gran medida, y reducir la cantidad general de errores liberados en el código de producción, y equivocado en el sentido de que ahora estamos trabajando más duro para evitar la necesidad de mantenga el código heredado, refactorizando constantemente el código y mejorando la arquitectura de tal manera que sea cada vez más raro que necesitemos desarrollar nuevos productos completamente desde cero.
Entonces, al final, ¿qué significa esto con respecto a la pregunta del OP? Bueno, significa que la respuesta realmente no es tan simple como podríamos haber pensado alguna vez. Hace 15 años, probablemente habría respondido la pregunta como un sí, pero ahora siento que es más realista decir que realmente es demasiado difícil de medir empíricamente, porque la naturaleza de lo que hacemos para desarrollar software ha cambiado mucho desde que comenzamos a hacernos la pregunta del OP en ese momento. De alguna manera, cuanto más avancemos en nuestras técnicas y habilidades como industria, más crecerá la pregunta desde un sí definitivo, hasta un punto en el que sospecho que en un corto número de años estaremos diciendo que no importa. cuando arreglemos errores, debido a que nuestras pruebas y procesos serán mucho más robustos, el tiempo de las correcciones de errores será menos impulsado por los esfuerzos para salvar nuestros presupuestos, y más por las prioridades para satisfacer las necesidades de nuestros clientes, y el costo relativo se vuelven virtualmente sin sentido contextualmente.
Pero como digo, esta no es una evidencia sólida respaldada por datos, solo mis observaciones de los últimos años, y mi instinto me dice que habrá más sabiduría innovadora que mejorará la forma en que hacemos las cosas.