Czas rozprawić się nieprawidłowymi przekonaniami na temat długu technicznego

Większość organizacji myśli o długu technicznym jako o ciężarze, którym trzeba zarządzać. Inne odnoszą większe sukcesy, traktując to jako ważną część codziennej pracy programisty.

Czas rozprawić się nieprawidłowymi przekonaniami na temat długu technicznego

Andy Kerr / Unsplash

Dług jest jak każda inna pułapka - dość łatwo w nią wpaść, za to bardzo trudno się z niej wydostać.”

-Josh Billings (amerykański humorysta)

To jedno z najbrudniejszych słów w technice. Podobnie jak w życiu, samo wspomnienie o długach wywołuje uczucie ciężaru i stresu. A wychodzenie z długów jest uciążliwe.

Zobacz również:

W inżynierii oprogramowania dług techniczny odnosi się do systemu, który się starzeje i pochłania cenny czas inżynierów. Dług techniczny to coś, czym trzeba zarządzać, utrzymywać go i minimalizować. To ostatnia rzecz na liście zaległości. W końcu wszystkich pogrąży.

Ale czy musi tak być?

Zyskująca na popularności wśród postępowych organizacji inżynierskich szkoła myślenia głosi, że dług techniczny powinien być kluczowym elementem pracy wszystkich programistów, a dzięki proaktywnemu zarządzaniu długiem technicznym zespoły te mogą nie tylko uniknąć zatonięcia, ale wręcz wyprzedzić konkurencję.

Co to jest dług techniczny?

Dług techniczny, którego nazwa pochodzi od informatyka Warda Cunninghama z 1992 roku, to koncepcja, zgodnie z którą tworzenie krótkoterminowych rozwiązań systemów technicznych pociąga za sobą zestaw kompromisów, skutkujących przyszłymi zobowiązaniami, które muszą zostać spłacone w formie pracy inżynierskiej.

Martin Fowler opisał to w 2003 r. jako twórca oprogramowania:

W tej metaforze robienie rzeczy w sposób szybki i brudny powoduje powstanie długu technicznego, który jest podobny do długu finansowego. Podobnie jak w przypadku długu finansowego, dług techniczny powoduje naliczanie odsetek, które mają postać dodatkowego wysiłku, jaki musimy włożyć w przyszły rozwój.

Według raportu Stripe’s Developer Coefficient z 2018 r. przeciętny programista spędza ponad 13 godzin tygodniowo na zajmowaniu się długiem technicznym. Obecnie, gdy aplikacje stają się coraz bardziej złożone, zarządzanie tym długiem nigdy nie było bardziej krytyczne. „Każdy kod, który został uznany za zobowiązanie, jest długiem technicznym” - mówi Alexandre Omeyer, dyrektor generalny Stepsize.

Dług techniczny przybiera bardzo różne formy. „Na niższym poziomie może to być mały obszar kodu, który wymaga refaktoryzacji, biblioteki, które wymagają aktualizacji, lub testy jednostkowe, które wymagają poprawek" - napisał w zeszłym roku Isaac Sacolick, felietonista InfoWorld. „W wyższych kategoriach dług techniczny obejmuje przebudowę złożonych, monolitycznych aplikacji, przeniesienie przestarzałych protokołów usług internetowych, konsolidację wielu platform do jednego standardu, oczyszczenie długu danych, modernizację infrastruktury, wprowadzenie praktyk obserwowalności lub automatyzację zaległych testów manualnych. Najgorszym rodzajem długu technicznego jest „płonąca platforma”, czyli platforma z powtarzającymi się awariami i incydentami, które mają wpływ na działalność firmy”.

Chociaż praca nad czymś, co określa się mianem „płonącej platformy”, może wydawać się mniej atrakcyjna niż dostarczanie nowych, błyszczących funkcji, to tylko zespołowe, proaktywne i ciągłe zajmowanie się długiem technicznym pozwoli programistom uniknąć bólu w dłuższej perspektywie.

„Zajmowanie się długiem technicznym często jest traktowane po macoszemu, ponieważ rzadko odnosi się do pilnej potrzeby biznesowej, a zwłaszcza w przypadkach, które nie są pilne, zwrot z inwestycji jest niejasny i dlatego postrzegany jako odroczony” - pisze Sacolick. „Jest to klasyczny problem dla wszystkiego, co wiąże się z utrzymaniem, zarówno kodu, jak i domów”.

Zaglądamy w otchłań długu technicznego

Mik Kersten, autor książki „Od projektu do produktu” i założyciel firmy Tasktop uważa, że „dług techniczny musi być pierwszorzędną sprawą, którą należy się zająć w sposób proaktywny. Niestety, w wielu przypadkach jest to nowa koncepcja”.

Dla wielu zespołów inżynierskich, szczególnie tych w szybko rozwijających się organizacjach, dług techniczny może sprawiać wrażenie, że stoi w sprzeczności z ważną pracą, jaką jest pompowanie nowych funkcji. Jednak dla Charity Majors, dyrektora technicznego i współzałożycielki firmy Honeycomb, dług techniczny sam w sobie jest „oznaką sukcesu - oznacza, że wciąż żyjesz”.

Tylko „dbając o małe rzeczy, można mieć pewność, że nie wyrosną one na wielkie gremliny” - powiedziała Majors w wywiadzie dla InfoWorld.

Choć łatwo to powiedzieć, w całej organizacji musi nastąpić zmiana kulturowa, aby dług techniczny był traktowany poważnie.

„Możliwość posiadania prawdziwych zaległości, którym nadaje się priorytety, jest wyzwaniem dla wielu przedsiębiorstw, zwłaszcza tych, które osiągnęły punkt, w którym mają bodźce do wprowadzania nowych rozwiązań, ale zazwyczaj nie mają żadnych konkretnych, opartych na wynikach bodźców do zarządzania długiem technicznym” - komentuje Rachel Stephens, analityk RedMonk.

Bądź też, jak powiedział Kersten z firmy Tasktop: „Zachęcając wyłącznie do wprowadzania funkcji, wpędzisz się w spiralę śmierci związaną z długiem technicznym”.

Jak przejąć kontrolę nad swoim długiem technicznym

John Kodumal, dyrektor techniczny i współzałożyciel LaunchDarkly, tłumaczy, że choć „dług techniczny jest nieunikniony w tworzeniu oprogramowania”, to proaktywne podejście do zmniejszania go w czasie jest „znacznie zdrowsze niż zatrzymywanie innych prac i próby wydostania się spod góry długu”.

To proaktywne podejście do problemu długu technicznego polega na traktowaniu wszystkiego, co można uznać za dług techniczny, jako kolejnego elementu pracy nad funkcjonalnością, który należy włączyć do normalnego procesu zwinnego.

„Sekret utrzymania aplikacji i uniknięcia, a przynajmniej opóźnienia, statusu spuścizny leży w sposobie, w jaki organizacje i zespoły zarządzają długiem technicznym” - pisze Sacolick. Kluczem jest bycie proaktywnym, co oznacza: „Ustanowienie polityki, konwencji i procesów, które pozwolą zamortyzować koszt redukcji zadłużenia w czasie”.

Wiele zespołów będzie miało pokusę, aby poświęcić pewną ilość czasu na walkę z długiem technicznym, np. 20% każdego sprintu. Kersten z firmy Tasktop radzi jednak przyjąć bardziej dynamiczne podejście, uwzględniające kontekst zbliżających się terminów lub możliwości zespołu.

„Należy mierzyć wyniki biznesowe i inwestycje w dług techniczny i upewnić się, że się one równoważą” - mówi Kersten. „Zadbaj o to, aby dług techniczny był widoczny, tak abyś zawsze wiedział, jak bardzo nim zarządzasz. Kiedy już będzie to widoczne, ustal docelową wartość procentową, która musi być dynamiczna w czasie”.

Dla Bena Kusa, CTO w firmie Box, zajmującej się przechowywaniem danych w chmurze, spłacanie długu technicznego jest czymś, co wszystkie zespoły inżynierskie muszą uwzględnić w swoim backlogu. „Oczywiście, to się przesuwa w czasie, ale powinno istnieć ciągłe poczucie, że stale zajmujemy się tymi sprawami” - mówi Kus, nie zaleca jednak wyznaczania określonych inżynierów do zajmowania się długiem technicznym. „Nie nazywajmy tego w ten sposób, bo właśnie stąd będzie się brało odejście” - mówi. „Nikt nie chce pracować nad długami technicznymi, refaktoryzacją czy innymi tego typu zadaniami”.

Zamiast tego w Box starają się równomiernie rozdzielać pracę między zespoły inżynierskie i ujawniać problemy w trakcie sprintu, w „postmortemach” i podczas dyżurów. „Mamy sztywny proces postmortem i identyfikujemy rzeczy do naprawienia, aby zapobiec ponownemu wystąpieniu tych samych problemów” - mówi Kus. „Nie jesteśmy tak aroganccy, aby powiedzieć 'rzuć wszystko, aby coś naprawić', ale jasno dajemy do zrozumienia, że jeśli problem się powtórzy, to będzie to kwestia odpowiedzialności. Jest to bardzo nieprzyjemne, jeśli coś dzieje się po raz drugi”.

Znaczenie rotacji na dyżurach

Ten element dyżurowania staje się coraz ważniejszy, ponieważ zespoły inżynierskie starają się skutecznie wykrywać i mierzyć długi techniczne, które je spowalniają.

Menedżerowie inżynieryjni, tacy jak Majors z Honeycomb, są zwolennikami regularnego odciągania inżynierów od pracy nad zadaniami, aby mogli dyżurować i skupić się na naprawianiu, refaktoryzacji i automatyzacji tego zadłużenia.

„Posiadanie w swoim zespole inżyniera, który jest odpowiedzialny przede wszystkim za małe rzeczy, jest bardzo ważne. A w ramach dyżuru należy aktywnie zniechęcać inżynierów do pracy nad produktami. To wprowadza elastyczność do systemu, który zazwyczaj ma jej bardzo mało” - mówi Majors.

Chris Evans jest założycielem Incident.io, startupu specjalizującego się w reagowaniu na incydenty. „Cały sens śledzenia spraw polega na usuwaniu wiedzy ukrytej. Zostaniesz wezwany do spraw, z którymi nie jesteś w stanie najlepiej sobie poradzić” – mówi. Choć na początku może się to wydawać przerażające, problemy zostaną naprawione, a wtedy, poprzez podkreślenie tego, co poszło nie tak, w trakcie prania po incydencie lub sekcji zwłok, znaczenie uporania się z długiem technicznym może stać się bardziej oczywiste. „Przyjmując odpowiedzialność operacyjną za wykonywaną pracę, zacieśniamy pętle sprzężenia zwrotnego między wysyłką a działaniem. Pomaga nam to podejmować pragmatyczne decyzje inżynierskie i zapewnia zdrowe napięcie między wysyłką nowego kodu a wspieraniem i ulepszaniem tego, co już mamy” - napisał Evans w grudniowym wpisie na blogu.

Na przykład, inżynierowie Incident.io zostali ostatnio spowolnieni przez interakcje z jedną z baz danych. „Dzięki tygodniowym inwestycjom jesteśmy w stanie stworzyć lepszy sposób interakcji z bazą danych, co będzie miało wpływ na sposób budowania każdej funkcji w przyszłości” - tłumaczy Evans.

A te sukcesy należy świętować tak samo, jak rozwiązanie poważnego incydentu czy wylądowanie nowej funkcji, niezależnie od tego, czy przybiera to formę Tiary Długu Technicznego Charity Majors, czy też celebracji Mik Kersten, która polega na „zabiciu dużego kawałka długu technicznego, jak zdobycie nowego klienta”.

Nowe podejście do długu technicznego w „Financial Times”

„Financial Times” przez ostatnie sześć lat zmieniał swoje podejście do długu technicznego. Jeszcze w 2015 roku strona internetowa brytyjskiej gazety była zasilana przez monolityczną aplikację o nazwie Falcon. W 2016 roku programiści firmy przekształcili Falcon w zestaw mikroserwisów, który teraz w całości nazywa się Next. Powstałe w ten sposób 332 repozytoria kodu są zarządzane przez szereg trwałych zespołów o określonym zakresie odpowiedzialności, od aplikacji, przez wyszukiwanie treści i reklamy, po centralną platformę, która odpowiada za 72 repozytoria.

„W ciągu mniej więcej roku wszystko zaczęło się psuć” - powiedziała Anna Shipman, dyrektor techniczny ds. produktów dla klientów w Financial Times, podczas kwietniowej konferencji QCon w Londynie.

Zespoły straciły z oczu ogólną strategię techniczną i to, kto jest właścicielem poszczególnych usług. Doprowadziło to do powstania rosnącego stosu długów technicznych, „nawiedzonych lasów”, czyli osieroconych baz kodu, których nikt nie chciał dotykać, oraz malejącej puli inżynierów gotowych do pełnienia dyżurów poza godzinami pracy.

Walka z tym problemem wymagała świadomego wysiłku w kierunku uporządkowania, usunięcia tych nawiedzonych lasów i zaakceptowania złożoności, tak aby można było nią skuteczniej zarządzać. Tylko wtedy, gdy zespoły posiadały wyraźną własność swoich stosów technologicznych, organizacja mogła zacząć bardziej świadomie atakować te techniczne długi i nawiedzone lasy.

„To nie jest coś, co można robić równolegle z regularnym dostarczaniem funkcji, ale coś, na co trzeba odpowiednio wygospodarować czas i zaplanować” - mówi Shipman.

Chociaż nie ma centralnego nakazu, aby przeznaczać, powiedzmy, 20% całego czasu pracy inżynierów na usuwanie nawiedzonych lasów i zarządzanie długiem technicznym, Shipman uważa, że zespoły są teraz lepiej przygotowane do zachowania równowagi między dostarczaniem funkcji a długiem technicznym.

Świetnie, a teraz przekonaj swojego szefa

Po ponownej ocenie relacji z długiem technicznym w całym dziale inżynieryjnym i zrozumieniu przez programistów wartości „spowolnienia” w celu bieżącego zajmowania się długiem technicznym, wyzwanie nie kończy się na tym. Trzeba jeszcze przekazać tę wartość kierownictwu wyższego szczebla.

„Menedżerowie ds. produktów i inżynierii poświęcają swój czas na dodawanie wartości biznesowej, tak jakby więcej dzwonków i gwizdków było jedyną wartością, ale czasami największą wartością jest tuning samochodu” - mówi Majors z firmy Honeycomb.

Zajęcie się długiem technicznym może być pierwszą rzeczą, która zostanie odłożona na dalszy plan w pogoni za celami biznesowymi, ale kierownicy działów technicznych muszą koniecznie zmienić tę narrację.

„Jedną z najczęstszych skarg, jakie słyszę podczas rozmów z inżynierami, jest poczucie, że muszą nieustannie pracować nad funkcjami, podczas gdy oprogramowanie i narzędzia, z którymi pracują, stają się coraz bardziej kruche, niespójne i frustrujące, a im samym coraz trudniej jest wykonać swoją pracę” - napisał David Van Couvering, starszy główny architekt w eBay, we wpisie na blogu na początku tego roku.

Przekazanie ryzyka związanego z tymi kruchymi systemami do biznesu często wymaga mówienia ich językiem, poprzez podkreślanie, w jaki sposób zajęcie się długiem technicznym już teraz może umożliwić inżynierom szybsze działanie w przyszłości, zapewnić większe bezpieczeństwo oprogramowania i sprawić, że będą zadowoleni lub powstrzymać ich przed odejściem.

„Kiedy nauczysz się mówić jak garnitur, skorzysta na tym Twoja firma, Twój zespół i Twoja kariera. Twoja firma zyskuje, ponieważ unika niepowodzeń, które mogą wynikać z nawarstwienia się pracy inżynierskiej” - napisał Van Couvering.

„Inni inżynierowie zrozumieją, jak ważna jest ta praca. Opowiedz historię, w której twój partner biznesowy będzie bohaterem, a ty zaufanym przewodnikiem. Musisz naprawdę odnieść się do wskaźników biznesowych, takich jak czas realizacji, wydajność i jakość” - radzi Shipman z Financial Times.

Nie podejmuj ryzyka

Skuteczne zarządzanie długiem technicznym będzie wymagało włożenia wiele wysiłku w zmianę zakorzenionych kultur i sposobów pracy, a także usprawnienia komunikacji między działem inżynieryjnym a szerzej pojętym biznesem. Być może trzeba będzie zmienić bodźce, na które pracują programiści, ale ryzyko związane z ignorowaniem rosnących stosów długu technicznego jest potencjalnie ogromne.

„Twój argument przeciwko długom technicznym będzie silniejszy, jeśli skupisz się na pomaganiu partnerom biznesowym w zrozumieniu, w jaki sposób dzisiejsze decyzje zwiększają przyszłe ryzyko. Porozmawiajcie o utracie przewidywalności projektu. Pokaż, jak obecne kompromisy prowadzą do pogorszenia wydajności w późniejszym czasie” - napisała w 2017 r. analityk RedMonk, Rachel Stephens.

Owszem, nowe, błyszczące funkcje uszczęśliwiają klientów i kierownictwo, ale systemy obciążone długami mogą spowodować, że wszystko się zatrzyma, a podnoszenie się z gruzów wcale nie wygląda na przyjemne.

Źródło: InfoWorld

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200