Dług techniczny, dług technologiczny

Często słyszę, jak te pojęcia są mylone i używane zamiennie, a tak naprawdę tyczą się zupełnie różnych rzeczy. Pokrótce postaram się przybliżyć oba te terminy, a także zaproponować sposób, jak z nimi żyć.

Dług technologiczny

Jest związany z tym, jakie technologie mamy w projekcie. Im technologie są starsze, tym dług większy. A co to dokładnie oznacza?

Dość klasycznym przykładem, z którym zmaga się prawdopodobnie większość z nas, jest brak migracji do nowszej wersji frameworka frontendowego. To niestety da się jeszcze zrozumieć, ponieważ nowe wersje pojawiają się dość często i trudno jest być na bieżąco.

Kolejnym przykładem, który może się automatycznie nasunąć, jest brak przejścia na najnowszą wersję języka w którym programujemy lub frameworka, którego używamy na backendzie. W świecie C# będzie to pisanie kodu w wersji C# wcześniejszej niż 8.0 (na dzień dzisiejszy) lub nieużywanie .NET Core.

Ostatnim przykładem, który zalicza się do długu technologicznego, są nieuaktualniane wersje bibliotek w naszych projektach.

Oczywiście na pierwszy rzut oka nie posiadanie najnowszych wersji nie wydaje się być dużym problemem. Jednakże nie należy tego lekceważyć i warto co jakiś czas zrobić migrację do nowszych wersji. Jeśli tego nie zrobimy, prawdopodobnie przyjdzie taki moment, że będziemy musieli podnieść naszą aktualną wersję o kilka wersji i wtedy mogą być spore problemy. O im więcej wersji będziemy musieli podnieść naszą aktualną wersję, tym bardziej narażamy się na więcej tzw. „breaking changes” – czyli zmian powodujących, że nasz obecny kod już nie działa i musimy go zmodyfikować.

Dług techniczny

Dług techniczny mamy wtedy, kiedy chcemy dodać nową funkcjonalność do naszej aplikacji, ale stary kod nam tego nie ułatwia. Zatem jeśli nie rozwijamy naszej aplikacji, to długu technicznego nie mamy – w przeciwieństwie do długu technologicznego, który pojawia się zawsze, gdy wyjdzie nowa wersja jakiegoś frameworka, biblioteki lub języka.

Jak to się więc dzieje, że taki dług w ogóle powstaje? Zakładając, że zawsze staramy się pisać najlepszy kod jaki potrafimy (jeśli tego nie robimy, polecam przeczytać ten post), to mimo to ciężko jest przewidzieć, w jakim kierunku nasza aplikacja się rozwinie. Nie wiemy jakie funkcjonalności będą potrzebne w przyszłości – oczywiście możemy przewidywać (zgadywać), ale z reguły to rynek weryfikuje co jest lub będzie potrzebne. Czasem również zdarza się tak, że tworzymy prostą funkcjonalność, jednak po jakimś czasie biznes postanawia ją rozszerzyć o dodatkowe funkcje, które nie współgrają z naszym aktualnym kodem.

Przy takim długu nie chodzi o to, aby go nie było – naszym celem jest go minimalizować. Powinniśmy zaciągać go świadomie, w jak najmniejszym stopniu i eliminować, gdy jest taka możliwość.

Jak radzić sobie z długami

Czy możemy coś zrobić, aby w pełni wyeliminować któryś z tych długów? Niestety nie. Jednakże to od nas zależy jak duże one będą.

Tetris

Bardzo spodobała mi się analogia Krzyśka Kędzierskiego. Porównał on wytwarzanie oprogramowania do gry Tetris. Można przyjąć, że:

• spadające klocki, to nowe funkcjonalności;
• czarne puste pola, które nam przeszkadzają, to dług (techniczny i technologiczny);
• za każdy razem, gdy uda nam się zająć cały pasek i on znika, to kolejny release.

Jeśli na planszy mamy dużo czarnych pustych pól (nasz dług jest duży), gra nam się ciężko i coraz trudniej jest umieścić gdzieś nowy klocek (dodać nową funkcjonalność). Może nam być również ciężko zapełnić pełen rządek (wydawać kolejną wersję). Ponadto jeśli ilość czarnych pól będzie się powiększać, może to doprowadzić do przegranej (nasz projekt stanie się nierozwijalny).

Co w związku z tym możemy zrobić? Naszym zadaniem jest dbanie o to, aby czarnych pustych pól było jak najmniej (nasz dług był jak najmniejszy). Jeśli ich ilość znacząco wzrasta, powinniśmy jak najszybciej doprowadzić do jej zmniejszenia. Niestety w świecie IT rzadko kiedy możemy sobie pozwolić na spowolnienie prac nad nowymi funkcjonalnościami i skupieniu się na spłaceniu długu technicznego, czy technologicznego. Dlatego dużo lepiej jeśli systematycznie będziemy dbali o eliminowanie czarnych pustych pól (zmniejszenie naszego długu). W niektórych sytuacjach może nawet uda nam się zlikwidować czarne puste pola z samego dołu planszy (pozbyć się długu zaciągniętego dawno temu). Co więcej dbając o to, aby ilość czarnych pustych pól była nieduża, powinniśmy być w stanie grać na prawdę długo (regularnie i bezproblemowo dodawać nowe funkcjonalności oraz wydawać kolejne wersje).