Dług technologiczny – najczęstszy powód wykolejania się projektów

Jakiś czas temu współtworzyłem produkt, który cieszył się dość dużym powodzeniem — był to panel do zarządzania hostingiem. Przez kilka lat nasza baza klientów rosła, a my rozszerzyliśmy panel o wsparcie nowych platform i dodawaliśmy nowe funkcjonalności. To był mój pierwszy “własny” produkt i stał się on dość popularny. W pewnym momencie był on używany przez większość dostawców hostingu gier w Polsce.

Wraz z tym, jak baza klientów rosła i poszerzyliśmy funkcjonalność aplikacji, zaczęliśmy obierać drogę na skróty. Czasami wynikało to z ograniczeń czasowych, innym razem myśleliśmy, że tak będzie po prostu dobrze.

Czas uciekał, a naprawianie błędów i dodawanie kolejnych funkcji stawało się coraz trudniejsze. Okazało się, że przez cały ten czas nieświadomie dolewaliśmy oliwy do ognia. Pewnego dnia okazało się, że nasz produkt przestał być opłacalny przez dług technologiczny, który sami podczas rozwoju produktu powiększaliśmy. Wydatki na utrzymanie produktu przerosły przychody, które był on w stanie generować.

my_servers

Musieliśmy podjąć trudną decyzję i porzucić projekt. Teraz wyobraź sobie, że jesteś w tej samej sytuacji: posiadasz większość udziałów w rynku i nie zarabiasz pieniędzy. To naprawdę niemiłe doświadczenie.

Ta sytuacja nauczyła mnie czegoś ważnego — oszczędzanie na jakości na dłuższą metę niesie za sobą większe straty i wydatki niż zarobki. Teraz jestem zażartym wrogiem długu technologicznego. W projektach, które prowadzę, zawsze staram się odpowiednio zadbać o jakość tworzonego kodu. Na samą myśl o długu technologicznym mam ciarki. Brr ;-/

Chwila. O jakim długu właściwie mówimy?

Dług technologiczny nie jest rzeczą fizyczną, namacalną. To metafora stworzona przez Warda Cunninghama, która pozwala na zrozumienie problemu, który się za nią kryje.

Dług technologiczny oznacza, że część systemu została stworzona w “prosty” sposób bez dbania o jakość kodu. Gdy oszczędzasz czas i pieniądze na rozwoju oprogramowania, Twój dług rośnie.

Tak samo jak dług finansowy, dług technologiczny niesie on za sobą odsetki, które musisz zapłacić. Im więcej długu zaciągasz, tym więcej odsetek. Jedyna różnica w tym przypadku jest taka, że nikt na Twoim długu nie zarabia — może jedynie prócz konkurencji, która zostawia Cię daleko w tyle.

Skąd bierze się dług technologiczny?

Dlaczego programiści wprowadzają dług technologiczny do projektu? Jest kilka powodów. Będę szczery — pierwszy powód nie jest zbyt przyjemny. Znaczna część deweloperów “zaciąga” dług, bo jest po prostu leniwa i wybiera łatwiejszą drogę wprowadzenia nowej funkcjonalności — bez myślenia o konsekwencjach.

Innym razem to młodzi i niedoświadczeni programiści zadłużają się technologicznie, bo nie do końca są świadomi tego, co robią, lub po prostu brakuje im pewnych umiejętności. Brak nadzoru nad takimi programistami może również doprowadzić do totalnego bałaganu w kodzie — który jest nawet gorszy niż dług technologiczny, ale to już inna historia…

Sytuacja, w której funkcjonalności muszą być stale implementowane w szybki i tani sposób jest dość powszechna w branży, szczególnie kiedy firma ściga się z konkurencją pod względem funkcjonalności. Mimo że, bycie pierwszym na rynku odpowiada potrzebom biznesowym, powinieneś pamiętać, że im szybciej wprowadzony dług zostanie spłacony, tym mniej będzie kosztował. Wiele firm mówi sobie, że zrealizuje teraz coś “na szybko”, a potem poprawi ten kod — niestety smutną prawdą jest, że wciąż za mało firm spłaca go szybko i odwleka spłatę do momentu, w którym jest już za późno, by miała ona sens. W takich przypadkach trzeba po prostu zacząć od nowa lub… porzucić projekt.

Czy w moim produkcie jest dług technologiczny?

Odpowiedz sobie na te pytania:

  • Czy rozwijanie oprogramowania jest spowolnione?
  • Czy zdarzają się częściowe lub całościowe przestoje w działaniu systemu?
  • Czy powracają te same błędy?
  • Czy czas wdrażania nowych funkcjonalności stale wzrasta?
  • Czy twoja aplikacja działa wolno?
  • Czy twoi programiści niechętnie pracują nad projektem?
  • Czy popychałeś zespół do wdrażania nowych funkcjonalności szybciej, niż było planowane?
  • Czy zdarzają się błędy trudne do odtworzenia lub rozwiązania?

Te pytania to tylko przykłady i oczywiście nie można ich na sztywno wiązać z długiem technologicznym, ale jeśli odpowiedziałeś TAK to warto się zastanowić czy przypadkiem nie masz już problemu.

Niezależnie od tego, czy jesteś świadomy długu, czy nie, możesz być pewny, że jeśli posiadasz jakiekolwiek oprogramowanie, posiadasz również jego dług i powinieneś go spłacić.

Jak duży jest mój dług?

Mam złe wieści — długu technologicznego nie da się zmierzyć. Są różne sposoby, które pomagają estymować wielkość długu, ale są tylko kiepskimi przybliżeniami, które mają niewiele wspólnego z rzeczywistością. Takie przybliżenia mogą jedynie pomóc w porównaniu różnych wersji Twojego systemu. Istnieją narzędzia, które pomagają zmierzyć przybliżoną wielkość długu, ale to temat na kolejny artykuł.

technical_debt_php

Czy dług technologiczny wpływa na mój biznes?

Tak, jak każdy dług, który zaciągasz. Nie dość, że posiadasz kod, który musi być refaktoryzowany (i musisz zapłacić za to programistom), to, co ważniejsze, im więcej długu posiadasz, tym dłużej zajmie Ci wprowadzanie nowych funkcjonalności. Innymi słowami, dług technologiczny zmniejsza Twoje możliwości szybkiego implementowania nowych funkcji. W niektórych przypadkach, gdy dług jest naprawdę duży, dodanie nowych funkcji w rozsądnym czasie i rozsądnym budżecie jest niewykonalne. To może doprowadzić do zatrzymania rozwoju oprogramowania i … dużych kłopotów.

Wyobraź sobie, utkwić w takim bałaganie i obserwować jak konkurencja z każdym dniem zwiększa swoją przewagę. Przerażające, prawda? Na szczęście, nie cały dług technologiczny jest groźny dla Twojego biznesu i dlatego nie cały musi być spłacony. Musisz tylko pamiętać, żeby trzymać go na niskim poziomie.

Dwa przypadki katastrofalnego wpływu długu technologicznego to Friendster i Knight Capitall. Friendster mógł być pierwszym portalem społecznościowym, ale stracił swoją szansę na zdobycie rynku ze względu na problemy związane z… zgadnij! Ich dług był tak duży, że strony ładowały się bardzo wolno, a platforma nie była w stanie szybko się skalować.

W Knight Capital stracili 440 milionów dolarów (!) w 45 sekund tylko dlatego, że mieli stary, nieprzetestowany kod wciąż zainstalowany na swoich serwerach. Możesz znaleźć dużo informacji na ten temat, bo to przypadek spowodował zamęt wokół notowań 148 firm, które znajdowały się na NYSE.

Co powinienem zrobić?

Jak wspomniałem wcześniej, trudno jest oszacować, jak duży dług posiadasz, więc najlepiej porozmawiaj o tym z Twoim zespołem. Mam nadzieję, że będzie z Tobą szczerzy i nikt nie będzie chciał ukrywać obecnego stanu oprogramowania. Może programiści już zaczęli Ci się skarżyć i sugerować, że jest coś, nad czym musicie popracować?

Najlepszym sposobem na zwalczenie długu technologicznego jest zbudowanie wspólnego zrozumienia wokół tego, czym ten dług jest i zmiana myślenia zespołu. Bardzo często najważniejszym krokiem jest ten, który zrobiłeś właśnie teraz. Masz już świadomość długu technologicznego i jeśli w tym momencie podejmiesz decyzję, żeby się z nim zmierzyć — jesteś na właściwej drodze.

  • Spróbuj dowiedzieć się jak najwięcej, czym jest dług technologiczny. Wiem, że już zacząłeś swoją edukację na ten temat, skoro czytasz ten artykuł – świetnie. Również product owner i cały zespół powinni mieć możliwość nauczyć się, czym jest dług technologiczny i jak on wpływa na Wasz biznes. Postaraj się, żeby każdy był świadomy istnienia długu i zastanów się ze swoim zespołem nad wspólnym opracowaniem rozwiązania tego problemu. Bardzo ważne, żeby zespół wiedział, co tworzy dług, jak go zidentyfikować i jak go unikać.
  • Razem stwórzcie proces zwalczania długu.
  • Podziel swoją aplikację na mniejsze, logiczne części, które mogą być refaktoryzowane osobno.
  • Zwracaj uwagę na jakość kodu, pisz automatyczne testy i zaplanuj odpowiednią ilość czasu na refaktoryzację.
  • Możesz również zaplanować specjalny dzień każdego tygodnia lub miesiąca na refaktoryzację/zmniejszanie długu technologicznego. Nadaj mu zabawną nazwę i ustal ciekawe zasady. Zamów pizzę i pozwól zespołowi porozmawiać na temat najważniejszych funkcjonalności. Później wspólnie nad tym pracuj.
  • Jeszcze raz: pozwól swoim deweloperom pisać automatyczne testy za każdym razem, gdy ktoś znajdzie błąd (test, który to będzie dokumentował). Staraj się dodawać test, zanim wdrożysz nowe funkcjonalności (Test Driven Development approach).
  • Nie zmuszaj zespołu do zbyt szybkiego dostarczania nowych funkcjonalności, jeśli nie ma ku temu dobrych powodów.

Keep calm and…

Doświadczyłem w swojej karierze niszczącego wpływ długu i pomagałem firmom, które męczyły się z nim i szukały rozwiązania. Niestety jest to tak powszechny problem, że jeśli chciałbym spisać wszystkie historie, które znam z własnych doświadczeń związanych z tym tematem, powstałaby raczej książka niż artykuł na bloga.

Najważniejsze to nie tracić nadziei — w większości przypadków nie jest za późno i można naprawić/spłacić zaciągnięty dług. Musisz tylko zrobić pierwszy krok i pokazać swojemu zespołowi właściwy kierunek w stronę światełka w tunelu. Sugeruję zrobić ten pierwszy krok już dziś, nawet jeśli miałby być on mały.

Współzałożyciel i CTO Accesto.com, ale przede wszystkim programista pasjonat. Gorący orędownik Software Craftsmanship, który stara się zarażać swoim podejściem osoby z otoczenia. Uwielbia poznawać nowe technologie i sprawdzać je w praktyce. Nieustannie walczy z kodem słabej jakości. Obecnie jedyny certyfikowany programista Symfony 3 w Polsce. Prywatnie tata, mąż i piwowar domowy.

  • aPoCoMiLogin

    Nie tylko programiści muszą mieć świadomość długu technologicznego, ale każdy kto w jakimś stopniu do rozwoju projektu się przyczynia. Co z tego że programista ma świadomość długu technologicznego, jeżeli dostanie odgórny „nakaz” zrobienia tego byle jak? Jeżeli w późniejszym etapie jest coś trudno zaimplementować w projekcie, to jeżeli programista tego nie widzi, dostrzec powinna to osoba która opłaca tego programistę.

    Niestety bardzo często jest tak, że na rynku jest masa „januszy biznesu” którzy nie rozumieją takich zagadnień, jak i nie wybiegają w przyszłość dalej niż do tego co zjedzą dzisiaj na obiad. Miałem tą „przyjemność” brać udział w projekcie, gdzie pracodawca wręcz nalegał aby kod był tworzony byle jak, byle by działało. Nie interesowało go nic innego jak czas implementacji czegoś, w danym momencie. W ogóle go nie interesowało co będzie za kilka miesięcy. A nawet jeżeli ty masz takie ideały, żeby kod przez ciebie tworzony był zgodny z obowiązującymi standardami, to zawsze znajdzie się ktoś, kto nie popiera twojego zdania, bo dla niego liczy się odfajkowanie tych ~8 godzin.

    To wszystko wygląda ładnie na papierku, że wystarczy stosować pewne schematy aby tego problemu uniknąć. Cóż, jak pracujesz sam nad jakimś projektem, to takie rzeczy są jak najbardziej możliwe, gorzej kiedy pracujesz w większym zespole i jesteś tylko ogniwem w łańcuchu..

    • Hugo WarsawDev

      Programiści tylko jęczą jaki to zły kod Pan manager każe im pisać. Że nie ma czasu na dobry kod. A ja się pytam, kto każe im się godzić na to?
      Profesjonalista jest profesjonalistą, między innymi dlatego, że potrafi powiedzieć NIE. „NIE, tak się nie robi, proszę zatrudnić, nieprofesjonalistę i niech to panu zrobi.”
      Po to zatrudnia się profesjonalistów, żeby to oni mówili jak się pracuje, a jak nie. Nie biznes, nie manager, ale programista ma znać i jasno wyznaczać granicę, ma uczyć biznes, że nie wszystko da się zrobić na już, bo oni tego chcą.
      Programiści tylko oczekują potulnie, aż ktoś im powie ok, teraz możecie pisać dobry kod.
      Nie to programista ma powiedzieć, sorry nie da rady tego zrobić w tyle i tyle. Wiem, że masz terminy, no ale to jest niewykonalne w takim czasie. Następnie usiąść spokojnie i robić w swoim tempie to co ma zrobić.

      Profesjonalny programista musi mieć jaja, żeby powiedzieć NIE. Inaczej nie może nazywać się profesjonalistą.
      „Janusz biznesu” ma się znać na biznesie, i pewnie liczy na to że zatrudnia nie „Janusza programistę”.
      „Janusz biznesu” może nie mieć zielonego pojęcia o wytwarzaniu oprogramowania, to programista jest od tego, żeby mu wytłumaczyć wszystko.
      Zastanówmy się jak to brzmi:
      Jestem profesjonalnym programistą, dostarczam kiepski kod, bo „Janusz Biznesu” mi tak, każe…
      Niestety jest często na odwrót, „Geniusz Biznesu” zatrudnia, „Januszy programowania”, którzy niszczą jego biznes.

      • aPoCoMiLogin

        Tak, programista nie powinien się zgadzać jeżeli jest mu coś nie na rękę (ktoś każe mu się uwsteczniać), ale życie nie zawsze jest kolorowe i nie zawsze można powiedzieć nie. Raz nie zawsze jest możliwość (małe miasto lub specyfika rzeczy którymi się zajmuje), a dwa nie zawsze można (kredyty, rodziny i inne zobowiązania).

        Osobiście wielokrotnie mówiłem nie, tak wiele razy odmawiałem tworzenia babolów (już nawet nie chodziło o kiepski kod, tylko same rozwiązania które są kiepskie), że przestali nawet z czasem pytać o zdanie, bo wiedzieli że tego nie będę robić byle jak. To że ja odmawiałem, nie znaczy że inni odmawiali. Więc wtedy można zmienić prace, ale powody wypisane wyżej mogą taką decyzje skreślać w przedbiegach.

        W swoim poprzednim komentarzu napisałem, że każdy kto bierze udział w projekcie, powinien mieć świadomość długu technologicznego. Nigdzie nie twierdziłem że tylko pracodawcy (janusze) mają na to wpływ, lub tylko programiści. Bo wpływ mają wszyscy.

        „Janusz biznesu” może nie mieć zielonego pojęcia o wytwarzaniu oprogramowania, to programista jest od tego, żeby mu wytłumaczyć wszystko.

        No i właśnie tutaj jest problem. Pracowałem w firmie gdzie był właśnie taki janusz, można było mu tłumaczyć do upadłego, wszystkie za i przeciw i że na dłużą metę się to nie kalkuluje, ale praktycznie za każdym jednym razem kończyło się to tak, że poszedł do innego programisty, który nie widział problemu w tym żeby taki badziew stworzyć. Celowo nazywam takich ludzi januszami, dlatego że zatrudniają specjalistę, po to żeby rozwiązywał problemy których oni nie rozumieją, ale i tak to się kończy tak, że idą tam, gdzie będzie im na rękę – tzn do kogoś kto pójdzie jemu na rękę.

        Jestem profesjonalnym programistą, dostarczam kiepski kod, bo „Janusz Biznesu” mi tak, każe…
        Niestety jest często na odwrót, „Geniusz Biznesu” zatrudnia, „Januszy programowania”, którzy niszczą jego biznes.

        biznes niszczy sobie sam, bo ostateczna decyzja należy do niego, bo to on płaci programiście.

        • sneer

          Zamień programistę na prawnika. Prawnikowi nikt nie powie, że chce mieć szybko byle jaką umowę, bo ma świadomość konsekwencji. W naszej branży góra nie ma świadomości albo jak ma to myśli jakoś to będzie. Też starci pieniądze jak w przypadku kiepskiej umowy ale będzie to bardziej rozmyte w czasie więc będzie mniej zauważalne przez niego.

          • aPoCoMiLogin

            Wychodzę z założenia że wszelkie zakazy i nakazy bardzo często mają odwrotny skutek od zamierzonego. Najlepsza jest edukacja i tłumaczenie dlaczego tak a nie inaczej. Tylko tak jak powtarzałem, każdy musi mieć świadomość problemów.

  • xd

    FUNKCJE!!! nie funkcjonalności!!!!

  • Jakiś czas temu zastanawiałem się nad tym, kiedy warto zaciągnąć dług technologiczny. Tutaj link: https://wojciszko.com/2015/10/12/kiedy-warto-zaciagnac-dlug-technologiczny/

  • A co myślisz o zaciąganiu długu technologicznego budując MVP/prototyp aplikacji? Tutaj celem jest jak najszybsze dostarczenie pierwszej, działającej wersji, która ma potwierdzić sensowność naszych działań.

    • aPoCoMiLogin

      Z doświadczenia mogę powiedzieć że zawsze kończy się to tak samo: czyli prototyp wdrążony produkcyjnie.

    • TL;DR; wszystko jest dla ludzi, tylko trzeba używać go z głową.

      Generalnie jeśli:
      1. zaciągasz dług bo uzyskasz dzięki niemu przewagę lub musisz coś zweryfikować
      2. planujesz go spłacać
      3. i go spłacasz
      4. dług jest zaciągnięty sensownie – nie fixujesz się na słabe technologie i zostawiasz sobie furtki w architekturze do poprawek
      to nie ma problemu. Liczy się sposób, należy zrobić to tak, aby możliwe było spłacenie długu niskim kosztem, po tym jak uzyskasz przewagę rynkową/zweryfikujesz swoje tezy i założenia.

      Uwaga na drugą stronę medalu, gdzie programiści szlifują w nieskończoność swój kod, ciągle przesuwając termin releasu.
      https://twitter.com/ziobrando/status/741186560373186560

  • Hugo WarsawDev

    To o czym piszesz to nie dług technologiczny, a dług architektoniczny.
    Możesz mieć bardzo dobry kod i architekturę napisaną w np. w c++(dodajmy jeszcze WinApi), którą bardzo dobrze i łatwo rozwija się, ale dziś to dług technologiczny.
    I odwrotnie.
    Możesz używać najnowszych technologii ale mieć do dupy programistów, którzy tworzą nierozwijalny kod. To dług architektoniczny.
    Zarówno jeden jak i drugi niosą za sobą koszta. Ale oba należy rozróżniać.

    • Jasne, możemy to dzielić i prawdopodobnie podział ma sens w momencie gdy omawiamy problem z osobą techniczną. Celem artykułu jest przybliżenie problemu biznesowi, żeby był świadomy problemu i rozsądnie długiem zarządzał.

      Dorzucę link jeszcze do Fowlera, gdzie „Technical Debt” oznacz właśnie to co poruszam w artykule
      http://martinfowler.com/bliki/TechnicalDebt.html

      • Hugo WarsawDev

        Jednak osobiście uważam, że biznes też powinien wiedzieć o tych dwóch różnych terminach.
        Co biznes powinien rozumieć, przez długi:
        – dług architektoniczny – masz kiepskich programistów, wymień ich jak najszybciej.
        -dług technologiczny – zainwestuj w aktualizację technologii, bo prawdopodobnie już płacisz więcej, a z czasem odsetki i sam koszt aktualizacji będą coraz większe – może miażdżące.

        Długiem architektonicznym biznes nie ma prawa zarządzać. Od tego płaci profesjonalistom, którzy mają dbać o to żeby takiego długu nie było. Dla mnie nie ma wytłumaczenia dla kiepskiej architektury.
        Biznes powinien zarządzać długiem technologicznym. Np. przepisujemy system desktopowy na webowy. Podbijamy się z .net x na najnowszy(są systemy, gdzie to nie takie proste). Zmieniamy knockout.js na angular’a. A my jako programiści, podejmujący się pracy w danej technologii mamy zrobić wszystko, żeby to było najlepszej jakości, bez względu czy jest dług technologiczny, czy go nie ma.

        Artykuł jak najbardziej na plus, ważne żeby biznes był świadomy istnienia długów. Ale też ważne, żeby wiedział która strona jest ich powodem.

        • aPoCoMiLogin

          No tak, za wszystko winni są programiści, nawet kiedy mówią nie, zwalniają się itp, a nasz janusz szuka sobie nowych programistów którzy zrobią to tak, jak on sobie wymarzył. Wszyscy muszą być świadomi problemów, łącznie z januszami.

  • Magdalena Mbn

    kiedy projekt zaczyna przynosić pierwsze zyski jakiś cwaniaczek z zarządu chce się do tych zysków podpiąć i wciska do projektu swoich ludzi którzy o programowaniu mają niewielkie pojęcie. Osoby które stworzyły system szukają innej pracy, a system jeszcze pewien czas działa silą rozpędu. Należałoby się ukorzyć przed twórcami i za wszelką cenę sciągnąć ich z powrotem ale po co ….

  • Piotr Bartnik

    Witam, super artykuł!

Send this to friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL
webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL