Non ho accesso a dati o fatti concreti, quindi posso offrirti solo osservazioni aneddotiche raccolte dai miei ultimi 20 anni in IT.
Credo che ci sia una grande differenza tra il modo in cui la maggior parte degli sviluppatori crea software oggi rispetto a 20 anni fa. Con il movimento Agile che ha guadagnato così tanto slancio, in particolare negli ultimi 5-6 anni, ho visto un vero cambiamento negli atteggiamenti sul posto di lavoro. Tanto che la qualità di ciò che facciamo sembra solo crescere a passi da gigante ogni anno e con ogni progetto mentre applichiamo le lezioni che abbiamo imparato da un progetto all'altro. I processi più snelli combinati con un'attenzione particolare allo sviluppo del primo test sono passati da molto controversi a banali. Al punto che entrare in molte aziende oggi, se non ti senti a tuo agio con Agile, sarai fortunato se non ti mostreranno la porta.
Quindi quale impatto ha avuto questo. Innanzitutto, ho notato che i problemi vengono spesso identificati molto prima. Spesso, se il problema non sembra troppo grave, a volte può essere sospeso a tempo indeterminato. In una rara manciata di casi, ho visto bug che erano ritenuti banali diventare problemi seri quando affrontati in seguito, poiché alcuni problemi fondamentali diventano evidenti che all'epoca non venivano considerati. A volte ciò può portare a un ciclo di correzione elaborato e può essere costoso in una certa misura, ma tale costo è spesso misurato in termini di risorse in misura minore e più spesso in termini di impatto sulla relazione tra cliente e sviluppatore. I clienti si stanno abituando a questo modo di pensare Agile, che restituisce loro risultati molto più velocemente di quanto non facesse ai vecchi tempi, con sprint di sviluppo altamente iterativi e rapido inversione di tendenza tra richieste e implementazione, quindi si sono aspettati molto da noi. E per quanto riguarda i bug effettivi, il tempo per risolvere un bug è molto più spesso ridotto a causa della presenza di una solida serie di test per supportare le modifiche e della capacità di creare nuovi test da cui fornire informazioni e soluzioni ai problemi segnalati.
Quindi, nel complesso, sembra che lo sforzo complessivo per correggere i bug sia stato ridotto nella maggior parte dei casi se esiste una solida serie di test e procedure per garantire che i test rimangano al centro di ciò che fa lo sviluppatore, ma il costo effettivo si è in qualche modo spostato in parte almeno dall'implementazione, ad altre aree del business, perché in qualche modo l'attenzione si è spostata dalla pura offerta e domanda alla gestione delle relazioni.
Un'altra cosa che è diventata evidente è che il nostro istinto intestinale di alcuni anni fa, che suggeriva che essere Agili avrebbe ridotto i nostri cicli di manutenzione, è stato dimostrato in modo giusto e sbagliato. Proprio nel senso che test solidi hanno reso più semplice il debug e la correzione del nostro codice in larga misura e la riduzione del numero complessivo di bug rilasciati nel codice di produzione, e sbagliato nel senso che ora stiamo lavorando di più per evitare di dover mantenere il codice legacy, eseguendo costantemente il refactoring del codice e migliorando l'architettura in modo che sta diventando sempre più raro che dobbiamo sviluppare nuovi prodotti completamente da zero.
Quindi, alla fine, cosa significa questo riguardo alla domanda del PO? Bene, significa che la risposta in realtà non è così semplice come avremmo potuto pensare. 15 anni fa, avrei probabilmente risposto alla domanda come Sì, ma ora ritengo sia più realistico affermare che è davvero troppo difficile misurare empiricamente, perché la natura di ciò che facciamo per sviluppare il software è molto cambiata da quando abbiamo iniziato a porsi la domanda del PO allora. In un certo senso, più avanziamo le nostre tecniche e competenze come industria, più la domanda cresce da un sì definitivo, a un punto in cui sospetto che tra un breve numero di anni diremo che non importa quando correggiamo i bug, poiché i nostri test e processi saranno molto più robusti, i tempi delle correzioni dei bug saranno meno guidati dagli sforzi per salvare i nostri budget e più dalle priorità per soddisfare le esigenze dei nostri clienti, e il costo relativo sarà diventa praticamente insignificante contestualmente.
Ma, come ho detto, questa non è una prova concreta supportata dai dati, ma solo le mie osservazioni degli ultimi anni e il mio istinto mi dice che ci sarà più saggezza rivoluzionaria a venire che migliorerà il modo in cui facciamo le cose.