Dług techniczny – co to jest (przyczyny i przykłady)

Wymówek na jego zaciągnięcie można mnożyć. Prawdopodobnie każdy programista (lub inżynier zajmujący się całkiem inną dyscypliną) kiedyś go zaciągnął. Czasem zaciągamy go z powodu braku czasu lub… złego oszacowania kosztów projektu i zbyt wąskiego patrzenia na pewne zagadnienia. O czym konkretnie mowa?

Dług techniczny lub technologiczny (inne nazwy to dług projektowy i dług kodowy od angielskiego: design debt i code debt) to zjawisko, w którym z powodu wybrania pozornie łatwiejszej i tańszej do zrealizowania opcji (lub drogi osiągnięcia konkretnego celu), całkowity koszt wyboru tej opcji staje się w dłuższej perspektywie czasu mniej opłacalny od wyboru bardziej czasochłonnego ale obiektywnie lepszego i bardziej dopracowanego rozwiązania.

Dług techniczny od błędu różni się właśnie tym, że dług technologiczny (tak jak zwykły dług pieniężny), jeżeli nie zostanie szybko „spłacony” to jego koszt spłaty będzie stale rósł. Im później chcemy naprawić to co wcześniej zaimplementowano niezgodnie ze standardem, tym więcej pracy bedzie wymagało jego usunięcie i naprawa jego oddziaływania na cały projekt. Najciekawsze jest to, że dług techniczny jest czasem w pełni zamierzony i gdyby nie on, to wiele projektów nigdy by nie powstało.

Skąd się bierze dług technologiczny?

• nieprecyzyjne lub ewoluujące wymagania w trakcie trwania projektu,
• presja wydania oprogramowania we wcześniejszym terminie niż zakładano,
• wydawanie produktu kiedy nie jest w pełni dokończony,
• zbyt sztywne hermetyczne rozwiązania uniemożliwiające łatwe dostosowanie do dodatkowych potrzeb (brak modularności zbyt wiele wzajemnych zależności),
• skupienie na szybkim uzyskiwaniu zysków, zamiast odroczyć przychody w początkowych fazach w imię możliwych korzyści osiągniętych później,
• brak dostosowania do standardów i dobrych praktyk w początkowych fazach, dostosowywanie do standardów w późniejszych fazach może być znacznie utrudnione.
• brak refaktoryzacji w początkowych fazach (późniejsza refaktoryzacja będzie bardziej problematyczna)
• brak kompetencji osoby zaangażowanych w projekt, która stosuję „drogę na skróty„,
• zmiany wymagań zbyt późno, w efekcie nie ma czasu ani budżetu by należycie wprowadzić je do projektu.

Skutki długu technicznego

• problem i zbyt wysoki koszt wprowadzania zmian w kodzie,
• wysoka liczba błędów i niepełne funkcjonowanie aplikacji,
• obniżenie wydajności, niezawodności, jakości lub wytrzymałości oprogramowania końcowego.

Przykłady i scenariusze długu technicznego

• rozwój aplikacji na frameworku, którego niewydajność w końcu staje się wąskim gardłem,
• brak utrzymania czytelności kodu, który staje się coraz bardziej problematyczny w miarę przybywania dodatkowego kodu,
• brak stosowania skalowalnych rozwiązań w przypadku powoli ale stale rosnących aplikacji i ich zapotrzebowania na zasoby.

Zalety długu technicznego

Czasem zaciągnięcie długu może być opłacalne. Przykładem może być przedwczesne wypuszczenie aplikacji i dopracowywanie jej w warunkach długu aby otrzymać cenny feedback od użytkowników.

Możliwość realizacji projektu nawet w przypadku braku kompetencji do jego „porządnego” wykonania.

Niższy koszt wytworzenia oprogramowania w przypadku, kiedy wiemy, że wkrótce powstanie nowa wersja od podstaw.

Podsumowanie

W pracy jako programista zaciągałem dług techniczny wiele razy. Mimo, że za każdym razem w pewnym momencie żałowałem, że go zaciągnąłem (kiedy w końcu musiałem go spłacić), cały czas kierując się ogólnym dobrem projektu rzadko kiedy stosuję rozwiązania, które można byłoby traktować jako wzorzec projektowy lub implementacyjny.

Źródła

https://www.techopedia.com/definition/27913/technical-debt