Z artykułu dowiesz się:

• Jakie są przyczyny długu technologicznego
• Jakie są rodzaje długu technologicznego
• W jaki sposób można zidentyfikować dług technologiczny
• Jakie są sposoby zapobiegania technologicznemu zadłużeniu

Przyczyny długu technologicznego. Nie bierze się znikąd…

Jak każdy inny dług, również dług technologiczny ma zawsze swoją przyczynę. Jest ona jednak inna niż w przypadku długu finansowego, chociaż w niektórych przypadkach oscyluje wokół pieniędzy. Długiem technologicznym nazywamy domniemany koszt związany z dodatkowymi poprawkami i przeróbkami w oprogramowaniu. Pojawia się on w momencie, kiedy firma wybiera niesprawdzone, tańsze i szybsze rozwiązania, rezygnując z tych naprawdę skutecznych. Może to wynikać m.in. z niedostatecznie dużego zespołu – obowiązki przewyższają zasoby i możliwości pracowników. To wymusza poszukiwanie alternatywnych rozwiązań dla wieloetapowego procesu projektowego. Aby przyspieszyć go, zespół rezygnuje z niektórych działań. Programistów gonią terminy, a w kolejce czekają już następne projekty. Jest presja czasu, a na dodatkowe ręce do pracy brakuje budżetu. Takie warunki pracy sprzyjają powstawaniu długu technologicznego.

Problemem jest również brak odpowiednich kompetencji do realizacji konkretnych zadań. Programowanie wymaga umiejętności, ale i doświadczenia. Powierzanie trudnych zadań początkującym specjalistom może skutkować błędami w kodzie, których naprawa potem jest związana z długimi i kosztownymi poprawkami. Ponadto programiści mają swoje obszary, w których się specjalizują. Przypisanie im projektów, które nie są z ich dziedziny, z nadzieją, że sobie poradzą, to także ryzyko pojawienia się długu technologicznego. Trzeba liczyć siły na zamiary i nie ryzykować z przekonaniem, że jakoś to będzie.

Nie można też zapominać o restrukturyzacji kodu. To proces, który jest związany z dodatkowymi kosztami, ale ma na celu bieżące dopracowywanie kodu. Jeśli zabraknie tych działań, istnieje ryzyko, że kod wraz z kolejnymi pracami będzie stawał się coraz mniej stabilny, bardziej podatny na niekorzystne zmiany i mniej wydajny.

To taki paradoks, którego firmy technologiczne i programiści mają świadomość, ale starają się wypierać myśli o skutkach swoich niedopracowanych projektów ze względu na oszczędności. Początkowo wydajemy mniej, udaje nam się zaoszczędzić, aby potem płacić za te oszczędności z nadwyżką. Wszelkie poprawki, które musisz wprowadzać, to Twój dodatkowy koszt – dług technologiczny. Tracisz czas, pieniądze i energię. Nie jest więc to najlepsza taktyka pracy.

Dług technologiczny długowi nierówny

Wyróżnia się kilka rodzajów długu technologicznego. Różnią się one od siebie okolicznościami wystąpienia, przyczyną, celowością i etapem, na którym się pojawiają. Jednym z nich jest celowy dług technologiczny. Jak sama nazwa wskazuje, jest on uwzględniany w budżecie przez firmę, ale do jego spłacenia dochodzi tylko w niektórych przypadkach. Pojawia się wtedy, kiedy w grę wchodzą terminy, trzeba szybko wypuścić oprogramowanie niezależnie od tego, jak bardzo będzie dopracowane. Może być to nawet jego podstawowa wersja. Organizacja w ten sposób sprawdza, czy oprogramowanie w ogóle się przyjmie. Jeśli tak, dług technologiczny należy jak najszybciej spłacić, a więc wdrożyć odpowiednie udoskonalenia. Jeśli tak się nie stanie, popadniemy w błędne koło i dług będzie się nawarstwiał.

Zupełnym przeciwieństwem celowego długu technologicznego jest dług niezamierzony. Nikt z programistów odpowiedzialnych za projekt go nie planował i nie zakładał, że mogą pojawić się jakieś problemy. Wynika on raczej z braku odpowiedniego doświadczenia i kompetencji specjalistów niż z pośpiechu. Błędy mogą pojawić się na wszystkich etapach projektowych. Jeśli przypadkowo źle zostanie zaprojektowana architektura, a więc fundament całego oprogramowania, to nic potem już nie działa tak, jak trzeba. Co więcej, nikt też nie wie, dlaczego tak się dzieje.

Czy niezamierzony dług technologiczny zdarza się tylko niedoświadczonym programistom? Oczywiście, że nie. Technologia wciąż się zmienia i jesteśmy zmuszeni do wdrażania nowych rozwiązań. Programista uczy się całe życie, dlatego potknięcia przytrafiają się nawet już wykwalifikowanym specjalistom, którzy dopiero zaczynają pracować na konkretnej, jeszcze niesprawdzonej technologii.

Jednym z częściej pojawiających się długów technologicznych jest dług dokumentacji. Tutaj wrogiem jest pośpiech. Kiedy zegar tyka, programiści mogą mniej uwagi poświęcać dokumentowaniu kodu. Co się wtedy dzieje? Jest on zwyczajnie niezrozumiały dla innych osób, co utrudnia wdrożenie nowych projektów. Nawet osoba, która napisała jakiś fragment danego kodu, po przerwie może nie być w stanie go prawidłowo odczytać. To nierzadko wywołuje lawinę błędów.

Może się też zdarzyć tak, że program zostanie prawidłowo napisany i wdrożony, ale na dalszych etapach zarządzanie nim pozostawia wiele do życzenia. W środowisku, w którym działa, zmienia się i ewoluuje, a program nie jest do niego dostosowywany. Wtedy przestaje on działań prawidłowo. Jeśli ta machina nie zostanie odpowiednio wcześnie zatrzymana, to dług technologiczny będzie narastał, a ostatecznie oprogramowanie przestanie działać.

Wyróżnić możemy jeszcze dług infrastruktury. Dotyczy on takich projektów, w których poszczególne komponenty infrastruktury są od siebie ściśle zależne. Brak szczegółowego określenia tych zależności skutkuje zaprzestaniem działania oprogramowania np. po jego migracji do nowej infrastruktury. Problem dotyczy też aktualizacji oprogramowania. Zaniedbanie w tym obszarze może nawet doprowadzić do cyberataków i kradzieży danych.

Dług technologiczny zdemaskowany

Czy dług technologiczny można zidentyfikować? Można, a nawet trzeba, jeśli chcemy go spłacić. Jeśli tego nie zrobimy, to będzie się pogłębiał. Jest z nim tak samo jak z długiem finansowym, kiedy wpadamy w pętle kredytową. Im dłużej to trwa, tym trudniej jest się z niej wyplątać.

Najłatwiej jest zidentyfikować celowy dług technologiczny, ponieważ najczęściej jest on udokumentowany jeszcze na etapie kodowania. Właśnie dlatego programiści wiedzą potem, które elementy wymagają poprawy. Planuje się spłatę długu, trzeba jednak jeszcze ten plan zrealizować, co nie zawsze jest takie oczywiste.

Znacznie więcej trudności pojawia się przy innych rodzajach długów technologicznych, kiedy ich zwyczajnie nie uwzględniliśmy w całym procesie tworzenia oprogramowania. Nie wiemy więc, skąd wynika błąd, ani gdzie go szukać. W takim przypadku ważne jest, aby przeprowadzić analizę logów błędów. Bardzo pomocna jest też analiza wydajności działania. Nie najlepszą praktyką jest unikanie opinii użytkowników. To oni mogą najwięcej powiedzieć Ci o tym, jak działa oprogramowanie. Powtarzające się błędy są właśnie tymi, które z dużym prawdopodobieństwem odpowiadają za dług technologiczny.

O tym, że mamy do czynienia z długiem technologicznym, świadczy też nieczytelny kod, który jest trudny do modyfikacji. To wpływa na trudności w rozwijaniu oprogramowania, jego przyszłość staje więc pod znakiem zapytania. Należy też szczególną uwagę zwrócić na dużą ilość martwego kodu, ale też takiego, który został np. zduplikowany. To oznacza, że coś jest nie tak.

Jak nie popaść w długi technologiczne?

Jeśli już popadłeś w dług technologiczny, to nie pozostaje Ci nic innego, jak spłacić go możliwie jak najszybciej. Nie uciekaj od problemu, ponieważ w ten sposób się go nie pozbędziesz, a pozwolisz mu narastać. Najlepszą jednak metodą walki z długiem technologicznym jest jego unikanie. Jak mówi stare dobre przysłowie, lepiej jest zapobiegać, niż leczyć.

Najprostszą techniką unikania długu technologicznego jest stworzenie zasad programowania, które będą dostępne dla każdego. To ogólne standardy i wytyczne, zgodnie z którymi pisany jest kod. Trzeba ich przestrzegać, wtedy jest duża szansa, że nie pojawią się błędy. Często też praktykuje się programowanie w parach, czyli tzw. pair programming. O co w nim chodzi? Jedna osoba piszę kod, a druga go monitoruje. Przechodzi on więc przez dwie pary rąk, dzięki czemu łatwiej jest wychwycić ewentualne niedociągnięcia. Specjaliści zamieniają się rolami co jakiś czas w parach, dzięki czemu każdy z nich ma szansę dodać coś od siebie. Jest to więc współpraca, a nie praca indywidualna, co jednak nie jest tak oczywistą umiejętnością w świecie programistów.

Aby uniknąć długu technologicznego, należy także wdrożyć praktykę refaktoryzacji kodu. Powinien on być na bieżąco poprawiany, aby ewentualne błędy nie generowały kolejnych. Kod łatwiej jest wtedy utrzymać i jest on zdecydowanie bardziej zrozumiały dla innych osób. Co więcej, zaleca się, aby programiści wdrażali testy automatyczne, podczas których szybciej i łatwiej można wykryć bugi. Poza tym są one mniej czasochłonne niż testy manualne, podczas których ryzyko niewychwycenia błędu przez testera jest nieco większe.

Długi technologiczne pojawiają się też rzadziej w firmach, w których korzysta się z narzędzi do zarządzania projektami. Mogą być to dedykowane programy lub ogólnodostępne, jak np. Trello czy Jira. Dzięki nim projekt łatwiej jest zaplanować, podzielić go na mniejsze etapy, przypisać je do poszczególnych pracowników, kontrolować przebieg i efekty prac zespołu, a także poprawić efektywność komunikacji pomiędzy pracownikami. Każdy wie, jaka jest jego funkcja, nie ma też wątpliwości, do kogo powinien się zwrócić w razie jakichkolwiek problemów. Błędy mogą być rozwiązywane wspólnie, a ich znalezienie jest łatwiejsze, ponieważ wiadomo, kto, za co odpowiada w projekcie.

Popaść w dług technologiczny nie jest trudno, sztuką jest się z niego wyplątać i odpowiednio szybko go spłacić. Technologiczne zadłużenie jest powszechnym problemem, ale można go uniknąć. Trzeba wypracować dobre praktyki projektowania, kontrolować stale kod, zadbać o sprawną komunikację w zespole i przede wszystkim przypisywać konkretne zadania kompetentnym osobom. I pamiętaj, pośpiech nie jest Twoim sprzymierzeńcem, a oszczędności generują w przyszłości najczęściej koszty.