niepotrzebnie użyłem argumentu "klient płaci". Nie jest to istotne
To jest bardzo istotne, wręcz kluczowe.
Sprawa jest prosta - jeśli program ma wielu użytkowników, albo chociaż jednego, ale dobrze płacącego, to warto go utrzymywać nawet jakby był napisany w Basicu ;)
A jeśli klient nie płaci/projekt jest na minusie, to trzeba to zaorać i to jak najszybciej.
Jak ktoś chce pisać dla radości pisania to się zapisuje do jakiegoś projektu OpenSource i tam pisze sa free. Firma ma na programie zarabiać i to jest podstawowy powód, dla którego firma oraz aplikacja istnieją.
przez kolejne 5 lat będziemy robić drobną zmianę raz lub dwa w roku a następnie kod staje się przestarzały bo zmieniają się technologie, biblioteki, praktyki
Ok, ale nadal można do takiego kodu wprowadzać zmiany. Nie jest to ani przyjemne, ani łatwe - niemniej, jeśli klient płaci, to powinno się to zrobić.
To o czym piszesz to raczej kwestia wyczucia momentu, w którym osoby zarządzające projektem powinny podjąć decyzję - czy aktualizujemy, czy zostawiamy jako legacy. Ale żeby taką decyzję podjąć, trzeba wiedzieć ilu userów mamy, ile oni płacą (czy opłaty abonamentowe, czy raczej za wykonane prace/aktualizacje/modyfikacje) - mając te dane da się ocenić, na ile takie przedsięwzięcie jest opłacalne. Bo równie dobrze może się okazać, że program sobie żyje własnym życiem, modyfikacje są bardzo rzadkie i poświęcenie setek czy tysięcy godzin na przerabianie całości to kasa i czas wywalone w błoto. Lepiej po prostu, jak będzie potrzeba, wykonać modyfikację, która by normalnie trwała 10 h w czasie 40h (bo legacy i stary fyf). Na tym konkretnym zleceniu jesteśmy 30h w plecy, ale całościowo to mamy zaoszczędzone kilkaset godzin, za które nikt by nie zapłacił.