fbpx

Dług techniczny, opcja call czy lokata długoterminowa?

5 komentarzy

  1. Konrad Garus pisze:

    Takie abstrakcyjne pokazanie zysku chyba nie przejdzie. Tego typu wzorki nie bardzo przystają do rzeczywistości.

    Moim skromnym chyba lepiej trzymać się wersji negatywnej. Ale też nie w wersji abstrakcyjnej (zaciągasz dług! papiery bez pokrycia!), tylko konkretnej: Właśnie straciłem dwie godziny szukając dokumentacji do naszej antycznej wersji serwera. Zmarnowałem pół dnia z powodu złej organizacji kodu w postaci miski spaghetti o 5000 liniach kodu. Ten bug, który właśnie wykrzaczył system w produkcji, powstał tylko dlatego, że dodawaliśmy małego ficzera w bardzo zagmatwanym kawałku kodu. I tak dalej.

    Sam regularnie wysyłam takie komunikaty (czasem działają!), ale i zastanawiam się nad wystawieniem w sieci publicznego licznika strat.

  2. ! Licznik to super pomysł. Coś na wzór licznika długu publicznego.

    Pomysł z negatywną lecz konkretną metaforą ma dla mnie jeden minus: informuje, że TERAZ powstał problem, z powodu tego co stało się WCZEŚNIEJ. Mam tu wątpliwości, ponieważ zleceniodawca może mieć trudności z uczeniem się na własnych błędach.

  3. Konrad Garus pisze:

    Prędzej nauczy się na własnych błędach ("właśnie straciłeś tyle i tyle kasy i mojego czasu, w którym mogłem ci sklepać następnego ficzera") niż zmieni cokolwiek na podstawie abstrakcyjnych metafor.

  4. devlab pisze:

    Wszystkiemu winni są Programiści. Zamiast tworzyć soft jak bozia przykazała (solidne testy, drobne refaktoryzacje podczas dodawania ficzerów), to ulegają presji czasu lub zwykłemu lenistwu i nie spłacają na bieżąco długu technologicznego. Dla mnie takie refaktoryzacje są zwykłym elementem codziennego rzemiosła i nie ma co straszyć/lukrować biznesu. Wystarczy tworzyć soft zgodnie z prawidłami. Jeśli Programista ma jakieś opory, należy go zapytać: "Czy po wyjściu z toalety spuszczasz po sobie wodę i myjesz ręce? Jeśli dbasz o higienę osobistą to dlaczego nie dbasz o higienę w projekcie?".

    Mówiąc Sponsorom: "dajcie kasę na refaktoryzację" sprawiamy że refaktoryzacja zaczyna być przez nich postrzegana jako odrębny proces, który nie ma żadnego uzasadnienie biznesowego. Nic dziwnego że nie chcą płacić.

    Cała sztuka w tym, aby refaktoryzować nie używając słowa "refaktoryzacja".

  5. Konrad Garus pisze:

    devlab, trochę idealizujesz. Są zadania, których nijak nie zrobisz w ramach codziennego rozwijania aplikacji.

    Używamy wersji serwera aplikacji / biblioteki, która już nie jest wspierana.

    Doszliśmy do miejsca, w którym okazało się że pewne zapytania / operacje / cokolwiek zaczynają być zbyt wolne.

    Odkryłem, że klasa / moduł / projekt, nad którymi pracuję są nie najlepiej zorganizowane i można by je podzielić.

    Odkryłem, że ta architektura sprawdzała się dobrze gdy mieliśmy prosty system służący 300 użytkownikom, ale już nie jest taka fajna jeśli uwzględni się dodane przez lata funkcjonalności, punkty wejścia, nagromadzone dane i fakt, że mamy już 5000 użytkowników.

    Rozwiązanie tego typu problemów to nie zadanie, które zrobisz między kawą a śniadaniem. A jeśli pracujesz nad czymś przez kilka lat, takie rzeczy po prostu muszą się pojawić.

    Pewnie, są drobnostki, które można rozwiązać w biegu w ramach codziennej higieny. Ale to nie one odpowiadają za najgorszy dług techniczny.