Dług techniczny

Dostarczanie niekompletnego oprogramowania można porównać do zadłużania się jego producenta u odbiorcy.

Gdy w marcu 1992 r. Ward Cunningham prezentował na konferencji OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) swoje doświadczenia z tworzenia oprogramowania do obsługi portfela inwestycji finansowych, nie mógł przypuszczać, że zastosowana przez niego metafora okaże się tak trafna i przydatna, że zacznie wieść własne życie. Na tyle bogate, że stanie się tematem konferencji i artykułów naukowych, raportów firm doradczych i wpisów na blogach. Przede wszystkim jednak będzie powszechnie używana przez organizacje tworzące oprogramowanie. Chodzi o dług techniczny (ang. technical debt). Stosując terminologię finansową, autor porównał dostarczanie nie w pełni kompletnego oprogramowania do zadłużania się.

Kod z dziurami

Wszyscy wiemy, jak obsługuje się kredyt zaciągnięty w banku. W określonym umową terminie spłacamy raty kapitałowe wraz z odsetkami, przy czym zwykle odsetki wyrażone są, niestety, liczbą dodatnią i stanowią koszt kapitału. Dlaczego się zadłużamy? Zadłużenie powoduje, że możemy zyskać więcej niż w przypadku, gdybyśmy się nie zadłużyli. Działa tu mechanizm tzw. dźwigni finansowej. Zadłużenie poprawia też (lub wręcz może uratować) naszą płynność finansową, czyniąc możliwym jakiekolwiek funkcjonowanie. Pierwszy rodzaj zadłużenia jest zwykle długoterminowy, a drugi - krótkoterminowy. Tak więc zadłużenie samo w sobie nie jest złe, o ile jest zaplanowane i obsługiwane.

Ward Cunningham, twórca Wiki

Pierwsza dostawa oprogramowania jest podobna do zadłużania się. Niewielkie zadłużenie przyspiesza wytwarzanie oprogramowania, o ile jest szybko spłacane poprzez przepisanie kodu źródłowego. Niebezpieczeństwo pojawia się wtedy, gdy dług nie jest spłacany. Każda minuta spędzona nad kodem wymagającym przepisania (ang. not-quite-right code) jest jak odsetki od długu. Organizacja wytwarzająca oprogramowanie może zatrzymać się z powodu obciążenia długiem - nieskonsolidowaną implementacją.

Co jest analogią pożyczki w przypadku oprogramowania? Nie do końca właściwie napisany kod źródłowy. Kod działający, ale z którego utrzymaniem i rozwojem mogą być w przyszłości problemy. Na przykład, kod słabo udokumentowany, nietrzymający się standardów obowiązujących w danej organizacji, kod zduplikowany czy osadzony w nieperspektywicznej architekturze oprogramowania. Należy zaznaczyć, że długiem technicznym nie są błędy w oprogramowaniu ani brakujące funkcjonalności produktu informatycznego. Chodzi przede wszystkim o jakość kodu źródłowego i perspektywiczność decyzji architektonicznych.

Przy takiej definicji długu technicznego możemy się zastanowić, skąd bierze się zadłużenie w oprogramowaniu. Powstaje ono głównie na skutek czynników związanych z:

- projektem lub produktem - presja czasu i ograniczenia budżetowe;

- zespołem wytwarzającym - braki w umiejętnościach, niedoświadczenie, niedokształcenie, czy wręcz beztroska programistów;

- procesem wytwarzania - słabo działające wbudowane mechanizmy dbania o jakość albo brak tych mechanizmów.

Przypadkowy i planowany

Przyglądając się tym czynnikom, Steve McConnell wyróżnił dług przypadkowy i planowany. Dług przypadkowy zaciągany jest nieświadomie, np. gdy niedoświadczony programista tworzy kod niskiej jakości lub gdy przedsiębiorstwo, w wyniku akwizycji producenta oprogramowania, staje się właścicielem kodu, w którym już zakumulował się dług techniczny. Dług planowany jest zaciągany świadomie, na skutek podjęcia decyzji w projekcie, przy czym może on być krótkoterminowy lub długoterminowy.

Krótkoterminowym długiem technicznym skutkuje np. decyzja: "Nie ma już czasu. Napiszmy ten fragment tak, aby jakoś działał. Potem go poprawimy". Długoterminowy dług tworzyć może natomiast decyzja o nieobsługiwaniu pewnej platformy sprzętowej, gdyż uznano, że jej obsługiwanie, nie jest potrzebne w tej chwili do osiągnięcia sukcesu rynkowego przez wytwarzane oprogramowanie. Należy zauważyć, że świadomie zaciągany dług techniczny jest dość łatwo monitorować.

Z kolei Martin Fowler dodał wymiar dotyczący podejścia zespołu projektowego do długu (beztroskie lub roztropne) i w ten sposób stworzył kwadrant długu technicznego.

Błędne koło

Zaciąganie i niespłacanie długu technicznego powoduje narastanie zadłużenia. Przez to oprogramowanie staje się bardziej złożone i trudniejsze do rozwijania, co z kolei zmniejsza produktywność zespołu, a nieubłagana presja terminów zwiększa się, co znowu prowadzi do dalszego zadłużania się, i tak dalej. Israel Gat z Cutter Consortium nazwał to błędnym kołem długu technicznego.

W skrajnym przypadku niespłacanie długu może spowodować, że stanie się on większy od wartości aktywów, czyli oprogramowania. Jedną z przyczyn porażki Netscape Navigatora, bezsprzecznego lidera na rynku przeglądarek internetowych w latach 90. ubiegłego stulecia, było właśnie opóźnienie dostarczenia nowej, konkurencyjnej wersji 6.0, spowodowane zbyt dużym obciążeniem kodu długiem technicznym. Na dodatek, gdy już ją dostarczono, to okazała się niestabilna i mało wydajna.

Jakość przegrywa z szybkością

Steve McDonnell, autor prac dotyczących projektowania software'u

[Dług techniczny to] zobowiązania zaciągane przez wytwórcę oprogramowania, gdy stosuje on takie podejście projektowe lub konstrukcyjne, które jest korzystne krótkoterminowo, ale zwiększa złożoność [oprogramowania] i jest bardziej kosztowne w perspektywie długoterminowej.

Jak sobie radzić z długiem technicznym? Długu przypadkowego należy unikać. Typowe metody prowadzące do unikania długu to edukacja pracowników czy wprowadzenie i przestrzeganie standardów kodowania. Praktyka pokazuje, że długu przypadkowego nie da się jednak uniknąć. Co wtedy? Należy dążyć do jak najszybszego jego wykrycia. Pomocne mogą być metody statyczne - np. zastosowanie analizatorów kodu źródłowego (pozwalających wychwycić nieprzestrzeganie standardów kodowania, duplikacje kodu, jego nadmierną złożoność - poprzez pomiar liczby cyklomatycznej) czy metody dynamiczne - takie jak ekstensywne testowanie.

Dług zaplanowany (a także wykryty dług przypadkowy) należy monitorować i spłacać. Monitorowanie może polegać na umieszczaniu w rejestrze produktu (w przypadku metodyk zwinnych) czy w harmonogramie (w przypadku metodyk bardziej tradycyjnych) zadań związanych z obsługą długu technicznego. Jawnie nazwane zadania związane z obsługą długu technicznego nie znikną z pola widzenia przy planowaniu prac.

Spłacanie długu to oczywiście realizacja zidentyfikowanych zadań, co nie jest wcale tak oczywiste. Jak zauważył Philippe Kuchten, w dzisiejszych czasach panuje kult szybkości, a nie jakości. Choć zwinne metodyki nie dyskryminują działań jakościowych, to praktyka pokazuje, że nacisk kładziony jest na dostarczanie wartości dla klienta, rozumianej głównie jako dostarczanie nowych funkcjonalności. Działania projakościowe mają mniejszy priorytet, co może skutkować ich odkładaniem, a w efekcie - nieuzasadnionym i nadmiernym zadłużeniem oprogramowania.

Dla lepszego zrozumienia

Metafora długu technicznego pozwala lepiej zrozumieć i zakomunikować istotę niezbędnych działań związanych z jakością w projektach wytwarzania oprogramowania. Jest też bardzo przydatna w komunikacji z użytkownikami biznesowymi. Może ona pomóc wyjaśnić, dlaczego wprowadzenie "drobnej" zmiany w działającym przecież oprogramowaniu ma zająć "aż tyle" czasu.

Równie ciekawa jest sytuacja, w której użytkownicy biznesowi są bezpośrednio zaangażowani w rozwój oprogramowania, a w szczególności uczestniczą w ustalaniu priorytetów implementacyjnych. Dzięki metaforze mogą oni lepiej zrozumieć implikacje możliwych wyborów. Co ciekawe, użytkownicy biznesowi chętniej niż programiści zaciągaliby dług techniczny. Ci drudzy mają skłonność do perfekcjonizmu.

Na zakończenie apel: Zadłużajmy się rozsądnie. Rozmawiajmy o zadłużeniu. Nie zwlekajmy więcej, niż jest to konieczne ze spłatą zaciągniętego długu technicznego. I nie bankrutujmy.

Wojciech Chybowski jest właścicielem firmy doradczej Domib.