Rozumienie długu technicznego

Z Wikipedii: “Dług techniczny (znany również jako dług projektowy lub dług kodu) to “koncepcja w programowaniu, która odzwierciedla dodatkową pracę deweloperską wynikającą z zastosowania kodu łatwego do zaimplementowania w krótkim terminie zamiast najlepszego ogólnego rozwiązania”.

Dług techniczny można porównać do pieniężnego długu. Jeśli dług techniczny nie zostanie spłacony, może narastać „odsetkami”, utrudniając późniejsze wprowadzanie zmian. Nieadresowany dług techniczny zwiększa entropię oprogramowania. Dług techniczny nie jest z konieczności czymś złym i czasem (np. jako proof-of-concept) jest wymagany, aby posuwać projekty naprzód. Z drugiej strony, niektórzy eksperci twierdzą, że metafora „długu technicznego” ma tendencję do minimalizowania jego wpływu, co skutkuje niewystarczającym priorytetyzowaniem prac niezbędnych do jego usunięcia.”

Koncepcja długu technicznego pochodzi ze świata inżynierii oprogramowania, ale ma równie duże zastosowanie w świecie infrastruktury IT i biznesowej. Podobnie jak w inżynierii oprogramowania, projektujemy nasze systemy i sieci, a stosowanie skrótów w projektach – w tym praca z nieoptymalnym designem, włączanie istniejącego sprzętu i inne złe praktyki projektowe – tworzy dług techniczny. Jedną z bardziej znaczących form tego zjawiska jest inwestowanie w „przeszłość” zamiast w „przyszłość”, co często jest wywoływane przez błąd utopionych kosztów (tzw. wrzucanie dobrych pieniędzy za złymi).

Łatwo zobaczyć, jak to się dzieje w firmach każdego dnia. Tworzone są nowe plany na przyszłość, ale zanim zostaną wdrożone, inwestuje się w utrzymanie starego systemu, jego ulepszanie, rozbudowę itp. Inwestycja ta zamienia się następnie albo w niemal natychmiastową stratę finansową, albo – co częstsze – staje się zachętą do nieprzyspieszania inwestycji w przyszłe projekty, mniej gruntownego podejścia do nich lub całkowitej rezygnacji. Inwestycja w przeszłość może być paraliżująca w najgorszych przypadkach.

Dzieje się to na wiele sposobów i zazwyczaj jest niezamierzone. Często inwestycje są potrzebne, aby utrzymać istniejący system w sprawności i w normalnych warunkach po prostu by zostały poczynione. Ale w sytuacji, gdy planowana lub potencjalnie rozważana jest zmiana na przyszłość, ta inwestycja może być problematyczna. W wielu przypadkach mogą temu zaradzić lepsza analiza kosztów i planowanie triażu.

W przykładzie spoza IT wyobraźmy sobie posiadanie starszego samochodu, który dobrze służył, ale za trzy miesiące ma zostać zastąpiony. Za trzy miesiące planujemy kupić nowy samochód, bo stary nie jest już opłacalny z powodu ciągłych potrzeb serwisowych, niższej efektywności i tym podobnych. Ale zanim minie trzy miesiące do zakupu nowego auta, stary samochód ulega drobnej awarii i wymaga znaczącej inwestycji, by nadal działał. Wkładanie pieniędzy w stary samochód byłoby nową inwestycją w dług techniczny. Zamiast wydawać duże pieniądze, by stary samochód jeździł przez kilka miesięcy, zdecydowanie rozsądniejsze finansowo jest przyspieszenie zakupu nowego. W przypadku samochodów widzimy to wyraźnie (w większości przypadków). Oszczędzamy pieniądze – potencjalnie sporo – kupując szybciej nowy samochód. Gdybyśmy zainwestowali mocno w stary, albo tracimy tę inwestycję po kilku miesiącach, albo ryzykujemy zaburzenie solidnego planowania finansowego zakupu nowego auta, które już zostało podjęte. Oba scenariusze są złe finansowo.

IT działa tak samo. Wydanie dużej sumy na utrzymanie starego systemu poczty elektronicznej na sześć miesięcy przed planowaną migracją do hostowanego systemu poczty byłoby najprawdopodobniej bardzo nierozważne. Inwestycja albo niemal natychmiast zostaje utracona, gdy stary system zostaje wycofany, albo podważa nasz dobry proces planowania i prowadzi do nieterminowej migracji lub wykonania jej niestarannie, bo pozwoliliśmy, by dług techniczny kierował naszymi decyzjami zamiast właściwego planowania.

Często słaby proces triażu lub brak odpowiednich uprawnień dla osób go prowadzących jest czynnikiem powodującym awaryjne inwestycje w dług techniczny zamiast szybkich inwestycji skierowanych w przyszłość. To tylko jeden obszar, gdzie poważne ulepszenia mogą rozwiązać problemy, ale jest to obszar kluczowy. Można temu również zaradzić, częściowo, przez planowanie scenariuszy „co jeśli”, aby mieć gotowe plany inwestycyjne na wypadek typowych lub oczekiwanych awarii, co może być tak proste jak zaplanowanie rozbudowy pojemności wynikającej ze wzrostu zanim planowanie systemowe wejdzie w grę.

Innym znakomitym przykładem typowego długu technicznego jest rozbudowa pojemności storage’u serwerowego. To scenariusz, który obserwuję z pewną częstotliwością i dobrze ilustruje dług techniczny. Firmom często zdarza się kupować serwery z niewystarczającą lokalną pojemnością przechowywania danych. Wcześniej czy później pojawia się potrzeba większej pojemności. Jeśli stanie się to od razu, widać, że zakupiony serwer był formą długu technicznego wynikającą z błędu projektowego i oczywistej wady w procesie planowania i zakupów.

Jednak częstszym przykładem jest konieczność rozbudowy storage’u dwa lub trzy lata po zakupie serwera. Typowe opcje rozbudowy obejmują dodanie zewnętrznego macierza storage’owego lub modyfikację serwera w celu przyjęcia większej lokalnej pojemności. Oba podejścia wymagają zazwyczaj dużych inwestycji w już stary serwer, który jest co najmniej w czterdziestu procentach przez swój przydatny okres eksploatacji. W wielu przypadkach ta sama lub tylko nieznacznie wyższa inwestycja w całkowicie nowy serwer może zapewnić nowy sprzęt, szybsze procesory, więcej RAM, potrzebny storage, celowo zaprojektowany i zbudowany, wyrównany i odświeżony okres wsparcia, mniejszy ślad w centrum danych, niższe zużycie energii, nowsze technologie i funkcje, lepsze relacje z dostawcą i więcej – przy zachowaniu oryginalnego serwera do ponownego użycia, wycofania lub odsprzedaży. Jeden sposób wydaje pieniądze na wspieranie przeszłości, drugi często pozwala wydać porównywalną kwotę na przyszłość.

Dług techniczny jest paraliżującym czynnikiem dla wielu firm. Zwiększa koszty IT, czasem znacznie, i może prowadzić do wysokiego poziomu ryzyka przez brak planowania i wydatkowanie środków głównie w trybie awaryjnym.