Friday, September 30, 2011

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

Standardowy kłopot z refaktoryzacją: my chcemy, a z góry leci głośnie NIE! Łaj? W moim odczuciu są dwie główne przyczyny. Pierwsza wynika z definicji. Skoro refaktoryzacja, to "ulepszenie wewnętrznej struktury oprogramowania, bez zmiany jego funkcjonalności", to skoro nie dodaje funkcjonalności, a zatem nie dodaje wartości biznesowej, a zatem nie pozwala efektywniej zarabiać, a zatem nie warto jej wykonywać. Podsumowując - kasa.
Drugi problem jest związany z przekonaniem, że jak już refaktoryzować, to rewolucyjnie i musi to zająć mnóstwo czasu. Skoro czasu to i pieniędzy. Za drogo i nie warto tego robić. Znów kasa. Nie zbłądzę zbytnio, gdy stwierdzę, że tarcia o refaktoryzację obijają się o pieniądze.

Kłopot z metaforami

Aby zdobyć choć trochę posłuchu u biznesu community wykombinowało jak na razie dwie metafory: Długu technicznego oraz (najświeższa) Niezabezpiecznonej opcji typu call.
Gdy się w nie wczytać, to każda z nich mówi mniej więcej coś takiego: Pamiętaj biznes-ludku, że jak nie będziemy refaktoryzować, to stanie się COŚ strasznego!. Obie metafory odwołują się do rzeczy, która jak nam się zdaje, najlepiej do biznesu przemówi, czyli do pieniędzy.

Dług techniczny mówi: zabraniając refaktoryzacji zaciągasz duże zobowiązanie, w kolejnym wydaniu rollujesz ten dług kolejnym długiem, i kolejnym, i kolejnym. W końcu zbankrutujesz i klops.
Niezabezpieczona opcja call mówi: nie pozwoliłeś na refaktoryzację, nabyłeś najbardziej ryzykowny instrument finansowy we Wszechświecie. Jedyne co możesz robić, to się modlić.

Skoro te metafory tak dokładnie wyłuszczają konsekwencje zaniedbywania jakości kodu, to dlaczego nic się nie zmienia? Nieco światła rzuca na to psychologia społeczna, wg której bardziej preferujemy natychmiastową gratyfikację niż długoterminowe korzyści oraz bardziej obawiamy się nieprzyjemności bliższych i namacalnych niż odległych i nieco abstrakcyjnych.

Podsumowując, twierdzę, że obojętność na prorefaktoryzacyjne błagania ma następujące przyczyny
  • korzyść z refaktoryzacji jest zbyt odroczona w czasie
  • korzyść z refaktoryzacji bardzo trudno wykazać jest w pieniądzach
  • zaniedbanie refaktoryzacji ma negatywne skutki w bliżej nieokreślonym kiedyś; a dopóki programiści mogą ratować projekt, to go ratują; czasem bardzo długo
  • robienie tak, "aby działało" ma szybkie odczuwalne korzyści
Powyższe fakty sprawiają, że na refaktoryzację przychodzi zgoda, gdy już w zasadzie jest za późno. I wtedy to już na prawdę jest od cholery roboty.

Lokata długoterminowa

Dobitna metafora dla refaktoryzacji powinna charakteryzować się następującymi cechami:
  • korzyści można łatwo wyrazić w pieniądzach
  • korzyści finansowe są szybko odczuwalne, powiedzmy w perspektywie tego samego albo najbliższego wydania
Zauważmy, że jest to metafora pozytywna. Dług techniczny oraz opcja call były metaforami negatywnymi w takim sensie, że straszyły tym, co złego się wydarzy jeśli nie będziesz grzeczny. Nasza nowa metafora jest sformułowana pozytywnie, bo pokazuje korzyści jakie uzyskasz, gdy będziesz się dobrze sprawować.

Szukałem tego typu metafory również w świecie finansów (no, bo dlaczego nie?) i znalazłem ja w postaci lokaty długoterminowej. Korzystając z tej metafory można w stronę Biznesu perorować, że:
  • refaktoryzacja jest jak wpłata pieniędzy na lokatę, już po pierwszym okresie rozliczeniowym następuje kapitalizacja odsetek i otrzymujesz swój procent
  • im dłużej oszczędzasz tym więcej zyskujesz
  • żeby osiągnąć maksymalną korzyść musisz wpłacać regularnie
  • jeśli zerwiesz lokatę, właściwie tracisz większość zarobku
  • no i w przypadku refaktoryzacji nie ma podatku Belki:), same korzyści!

A jak pokazać korzyści finansowe?

Tu popuszczam trochę wodze fantazji. Można spokojnie założyć, że na refaktoryzacyjnej lokacie odsetki procentują razem z początkowym kapitałem. Weźmy sobie zatem wzorek:
gdzie: V - obecna wartość, V0 - początkowy kapitał, r - stopa procentowa, n - liczba okresów rozliczeniowych.

No, to teraz spróbujmy zinterpretować wzór w kontekście refaktoryzacji. Vx - liczmy dalej w pieniądzach, n - liczba iteracji, a r? Skoro finansowo odpowiada to zyskowności (potencjałowi wzrostu kapitału?), to co jest tego odpowiednikiem w projekcie? Mam feeling, że coś z jakością kodu, ale nie bardzo wiem co.

5 comments:

  1. 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.

    ReplyDelete
  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.

    ReplyDelete
  3. 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.

    ReplyDelete
  4. 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".

    ReplyDelete
  5. 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.

    ReplyDelete