Produkt działa, ale jest mnóstwo bugów, a każda zmiana zajmuje coraz więcej czasu: co ustabilizować przed dalszym rozwojem?

Najdroższy moment w życiu produktu nie zawsze wygląda jak awaria. Czasem system działa, użytkownicy nadal z niego korzystają, a firma nadal zarabia. Problem widać dopiero przy kolejnej zmianie: poprawka, która miała zająć dzień, uruchamia kilka dni sprawdzania, ręcznych obejść i wyjaśniania, dlaczego w innym miejscu pojawił się nowy błąd.

Po kilku takich sytuacjach zespół przestaje pytać „ile zajmie funkcja?”. Zaczyna pytać „co tym razem się zepsuje?”. To nie jest wyłącznie problem tempa programowania. To sygnał, że koszt każdej zmiany rośnie szybciej niż wartość, którą ta zmiana ma dostarczyć.

W tym artykule rozkładamy ten problem na cztery pytania: skąd bierze się rework i opóźnienie, dlaczego kontekst znika po rotacji wykonawców, jak integracje i dane zwiększają koszt oraz co warto ustabilizować przed kolejną funkcją. Celem nie jest znalezienie winnego ani namawianie do pełnego rewrite’u. Celem jest wybranie pierwszego obszaru, który trzeba przestać zgadywać.