Nie mam dostępu do twardych danych ani faktów, dlatego mogę jedynie przedstawić anegdotyczne spostrzeżenia zebrane podczas ostatnich 20 lat pracy w branży IT.
Uważam, że istnieje ogromna różnica między sposobem, w jaki większość programistów tworzy dziś oprogramowanie, w porównaniu do 20 lat temu. Ponieważ ruch Agile nabrał tak dużego rozpędu, szczególnie w ciągu ostatnich 5-6 lat, zaobserwowałem prawdziwą zmianę postaw w miejscu pracy. Tak bardzo, że jakość tego, co robimy, wydaje się rosnąć skokowo z każdym rokiem, a wraz z każdym projektem, gdy wykorzystujemy wnioski wyciągnięte z projektu do projektu. Uproszczone procesy w połączeniu z naciskiem na rozwój w pierwszej fazie testów stały się bardzo kontrowersyjne i stały się powszechne. Do tego stopnia, że wchodząc dzisiaj do wielu firm, jeśli nie czujesz się dobrze z Agile, będziesz mieć szczęście, jeśli nie pokażą ci drzwi.
Jaki miał to wpływ. Przede wszystkim zauważyłem, że problemy często identyfikowane są znacznie wcześniej. Często zdarza się, że jeśli problem nie wydaje się zbyt duży, czasami można go odłożyć na czas nieokreślony. W rzadkiej garstce przypadków widziałem, że błędy, które uważano za trywialne, stają się poważnymi problemami, gdy zostaną rozwiązane później, ponieważ niektóre podstawowe kwestie stają się oczywiste, które nie były wówczas rozpatrywane. Czasami może to prowadzić do wyciągnięcia cyklu napraw, co może być do pewnego stopnia kosztowne, ale koszt ten jest często mierzony mniej pod względem zasobów, a częściej pod względem wpływu na relacje między klientem a deweloperem. Klienci przyzwyczajają się do tego zwinnego sposobu myślenia, który zwraca im wyniki znacznie szybciej niż w dawnych czasach, dzięki wysoce iteracyjnym sprintom programistycznym i szybkiemu przetwarzaniu wniosków i implementacji, więc oni oczekują od nas wielu. Jeśli chodzi o rzeczywiste błędy, czas na naprawienie błędu jest znacznie znacznie skrócony w wyniku posiadania solidnego zestawu testów do obsługi zmian oraz możliwości tworzenia nowych testów, na podstawie których można uzyskać wgląd i rozwiązania do zgłoszonych problemów.
Ogólnie rzecz biorąc, wydaje się, że ogólny wysiłek w celu naprawienia błędów został w większości przypadków zmniejszony, jeśli istnieje solidny zestaw testów i procedur zapewniających, że testowanie pozostaje w centrum uwagi tego, co robi programista, ale rzeczywisty koszt w pewnym sensie przeniosło się częściowo z wdrożenia na inne obszary działalności, ponieważ w pewnym sensie skupiono się również na czystej podaży i popycie na zarządzaniu relacjami.
Inną rzeczą, która stała się oczywista, jest to, że nasze instynkty jelitowe sprzed kilku lat, które sugerowały, że zwinność skróci nasze cykle konserwacji, zostały udowodnione w pewnym stopniu zarówno dobrze, jak i źle. W tym sensie, że rzetelne testowanie ułatwiło debugowanie i naprawę naszego kodu w dużym stopniu, a także w celu zmniejszenia ogólnej liczby błędów opublikowanych w kodzie produkcyjnym, i źle, w tym sensie, że teraz pracujemy ciężej, aby uniknąć konieczności zachowujemy starszy kod, stale zmieniając kod i ulepszając architekturę, tak że coraz rzadziej musimy opracowywać nowe produkty całkowicie od zera.
A więc w końcu, co to oznacza w odniesieniu do pytania PO? Cóż, oznacza to, że odpowiedź naprawdę nie jest tak wycięta i sucha, jak moglibyśmy kiedyś sądzić. 15 lat temu prawdopodobnie odpowiedziałbym na to pytanie tak, ale teraz uważam, że bardziej realistyczne jest stwierdzenie, że naprawdę trudno jest zmierzyć empirycznie, ponieważ natura tego, co robimy, aby opracować oprogramowanie, zmieniła się znacznie od czasu, kiedy zaczęliśmy zadawać sobie pytanie OP. W pewnym sensie, im bardziej rozwijamy nasze techniki i umiejętności w branży, tym bardziej pytanie rośnie od ostatecznego tak, do momentu, w którym podejrzewam, że za kilka lat będziemy mówić, że to nie ma znaczenia kiedy naprawimy błędy, ponieważ nasze testy i procesy będą o wiele bardziej niezawodne, że czas naprawiania błędów będzie mniej zależny od wysiłków zmierzających do oszczędzania naszych budżetów, a bardziej od priorytetów zaspokajających potrzeby naszych klientów, a względny koszt będzie stają się praktycznie bez znaczenia kontekstowo.
Ale, jak mówię, nie są to dowody oparte na twardych danych, tylko moje obserwacje z ostatnich kilku lat i moje przeczucie mówiące, że będzie więcej wstrząsającej wiedzy, która poprawi sposób, w jaki robimy różne rzeczy.