Tehnički dug u razvoju softvera nastaje kada se zbog brzine razvoja i tržišnog pritiska donose kompromisi u kvalitetu koda kako bi se funkcionalnosti što pre isporučile korisnicima. Takve odluke često kratkoročno ubrzavaju razvoj, ali dugoročno mogu usporiti dalji napredak sistema i otežati uvođenje novih funkcija. Problem se dodatno produbljuje kada se arhitektonske odluke donose bez dovoljno vremena za analizu, dokumentaciju i saradnju među članovima tima.
Posledice nagomilanog tehničkog duga ogledaju se u većim troškovima održavanja, sporijem razvoju, čestim greškama i lošijem korisničkom iskustvu. Zbog toga se u praksi nastoji pronaći balans između brzine razvoja i kvaliteta, uz planirano i kontinuirano smanjenje tehničkog duga tokom životnog ciklusa softvera.
Rukovodilac studijskog programa „Primenjeno softversko inženjerstvo“ na Fakultetu tehničkih nauka u Novom Sadu, vanr. prof. dr Aleksandar Selakov, smatra da se koncept tehničkog duga razvijao kroz vreme tako što je samo rastao, te da nije ni postojao do pre dve decenije. Dok je danas veoma prisutan. I da mu je najviše doprinela brzina razvoja.
„Kompetitivni pritisak u današnjoj softverskoj industriji je ogroman, tako da se kompanije često odlučuju da, svesno čak, ulaze u tehnički dug zbog brže isporuke „feature“-a. Nekada je to i posledica bržeg razvoja i želje da se time-to-market vreme smanji, da li za naš proof-of-concept, da li za finalni proizvod ili kasnije za nove “feature” koje market očekuje – mi svesno pravimo tehnički dug. To je ono, što programeri kažu, “budžimo”. Prosto, uradimo nešto samo da radi, da “feature” postoji, korisnik može da dobije funkcionalnost koju želi, a to je “ispod haube” bukvalno napravljeno od “štapa i kanapa”, kaže Selakov.
Kao najveći dugoročni problem on vidi, kasnije usporenje razvoja. Gde u jednom momentu, po njegovom viđenju, dalji razvoj neće biti ni moguć dok se ne reše infrastrukturni problemi koji su napravljeni.
“To bi bilo kao kuća kojoj smo zbrzali temelje. Mi možemo da nastavimo da zidamo, ali posle ćemo morati da srušimo nešto i da pravimo ispočetka. Koštaće nas na kraju ukupno vreme, koje smo utrošili na razvoj svih modula, cele aplikacije, više nego da smo radili sve kako treba”, upozorava Selakov.
Prevencija tehničkog duga je po njegovom mišljenju u menadžmentu odluka, a da je uloga obrazovanja u tome da programeri tokom rada ne načine nesvesno poteze koji vode u tehnički dug.
“Menadžment odluke, da se poštuju procene programera, pogotovo softverskih arhitekata, onih koji su zaduženi za infrastrukturu i planiranje, ako kažu da je za nešto potrebno četiri meseca, da se dodele četiri meseca da se to napravi. Ne dva meseca pod pritiskom marketa. Naravno, nekada je to neophodno da bi firma opstala, to je potpuno jasno i opravdano. Ali, ako pričamo svesno o tehničkom dugu, rešenje bi bilo poštovanje procene arhitekture koliko je potrebno za razvoj”, zaključuje Selakov.
Nenad Mirkov, CEO u kompaniji Auxality, objašnjava da se tehnički dug najčešće stvara, najjednostavnije rečeno, kroz pritisak i kratke vremenske rokove da se funkcionalnost isporuči.
“Menadžment je uvek fokusiran na produktivnost, klijenti često očekuju kraće rokove, i onda se bira prečica. Ostavlja se negde u beklogu plan da se stvari "srede" kasnije, ali to kasnije vrlo retko dođe jer uvek “gori” nešto novo”, objašnjava Mirkov.
Vrlo često, po njegovom viđenju, dug nastaje i pogrešnim dodeljivanjem zadataka i odgovornosti.
“Bitne arhitektonske odluke treba donositi sporije, uz učešće senior arhitekata i developera kroz zajedničke sesije razmene ideja. Ako jedna osoba sama donosi važne odluke i postavlja arhitekturu, pa još to ne dokumentuje i ne podeli sa ostalima na vreme - to vrlo često ostaje tako i kada nastane svest da to nije najbolje rešenje. Ovo dolazi na naplatu tek kasnije kada sistem treba nadograditi”, kaže Mirkov.
Naglašava ulogu ljudskog faktora, te da različiti ljudi imaju različit prag za ono što smatraju "dovoljno dobrim", što je u praksi dosta teško iskontrolisati.
Na pitanje kada tehnički dug postaje ozbiljan problem, a ne samo „nužno zlo", Mirkov odgovara analogijom: u električnom kolu, otpor se manifestuje kao toplota. U razvoju softvera, manifestuje se kao tehnički dug.
“Pitanje je, naravno, koliko toplote možemo da podnesemo pre nego što nešto pregori”, poentira on.
Mirkov smatra da tehnički dug postaje ozbiljan problem kada razvoj novih funkcionalnosti i održavanje postojećih košta više nego da se počne ispočetka. I za to ima konkretnu računicu.
“Kada se zbog nagomilanog duga za rešavanje jednog problema organizuje sastanak od 30 minuta sa četvoro ljudi, to je 2 sata fokusiranog rada jednog senior developera potrošeno na koordinaciju oko nečeg što ne bi trebalo da bude problem. Pretvorite to u seniorsku satnicu i jasno se vidi koliko zanemareni kod zapravo košta. A tu nisu uračunati frustracija tima i nervozan klijent”, računica je Mirkova.
Govoreći o primerima kada je dug usporio ili ugrozio projekat, Mirkov svedoči da su na početku njihove saradnje sa velikim regulisanim kompanijama u finansijskom sektoru radili tzv. "lift and shift", preuzimali su celokupna rešenja koja su radili timovi sa kojima više nije bilo moguće stupiti u kontakt.
U tim slučajevima, kako kaže, dokumentacije skoro da uopšte nije bilo, izuzev vrlo malo komentara u kodu, pa su ove sisteme morali ne samo da preuzmu i održavaju, već vrlo često i da izmene ili dograde novu funkcionalnost.
“Svaka takva izmena i isporuka je kao hodanje po minskom polju. Vreme koje se trošilo je višestruko veće nego što bi bilo potrebno da se sistem redovno održavao i da nije postojalo nagomilanog tehničkog duga”, kaže Mirkov.
Dodaje, međutim, da nisu samo stari sistemi problem.
“Mi razvijamo i potpuno nove proizvode i tu se isto suočavamo sa istim izazovima, ne zbog nedostatka znanja i kompetencija, već zbog prebrzog trčanja i jurnjave sa rokovima, i ponekad loše organizovanosti posla. Ako se ovi problemi ne adresiraju pravovremeno, vraćaju se kao bumerang”, dodaje Mirkov.
Njegov konačni zaključak jeste - dug najčešće ne boli dok si mali.
“Boli kada porasteš, a tada je obično prekasno za jeftine popravke”, zaključuje Mirkov.
CTO u ConcordSoft-u Mladen Prijić smatra da je balans između brzine i kvaliteta jedan od ključnih izazova u razvoju softvera.
“U praksi, ne posmatramo ih kao suprotnosti, već kao dve strane iste strategije. Fokusiramo se na isporuku vrednosti korisnicima u kratkim ciklusnim fazama. Koristimo principe kao što su code review, automatizovano testiranje i kontinuirana integracija kako bismo obezbedili da i kada radimo brzo, radimo održivo”, kaže Prijić.
U njegovoj kompaniji tehnički dug posmatraju kao neizbežan deo razvoja, ali nešto čime se aktivno upravlja i tretira kao vidljiv i merljiv deo razvoja.
“Merimo ga kombinacijom kvantitativnih i kvalitativnih pokazatelja - kroz alate za analizu koda, broj bugova, kompleksnost sistema, kao i kroz feedback samog razvojnog tima. Na taj način možemo da ga prioritetizujemo i planiramo njegovo rešavanje u skladu sa poslovnim ciljevima”, kaže Prijić.
Odluka da se fokusiraju na smanjenje tehničkog duga donosi se, po njegovom viđenju, onda kada on počne da utiče na brzinu razvoja, stabilnost sistema ili kvalitet isporuke.
“Drugim rečima, kada dug počne da usporava inovaciju, tada postaje prioritet. U praksi, ne čekamo da problem eskalira, već redovno izdvajamo deo kapaciteta tima za njegovo smanjenje. Pored toga, u ključnim momentima, kao što su skaliranje sistema ili uvođenje novih funkcionalnosti, svesno pravimo korak unazad kako bismo dugoročno omogućili brži i stabilniji razvoj”, kaže Prijić.
Za produkt menadžera Ananas-a Nikolu Domazeta tehnički dug podrazumeva da su prilikom kreiranja i lansiranja neke nove funkcionalnosti morali da naprave određene kompromise.
„Kao i svaki dug, u jednom momentu mora da dođe na naplatu, a to se najčešće dešava u trenutku planiranja nove roadmap-e ili neke drugačije funkcionalnosti“, svedoči Domazet.
Konkretni načini na koje tehnički dug može da uzrokuje ograničenja najčešće se, iz njegovog iskustva, ogledaju u usporavanju vremena koje je potrebno da nova funkcionalnost ugleda svetlost dana ili, popularno rečeno, usporava tzv. time-to-market.
„Dakle, što je sistem kompleksniji i opterećeniji starim, „zakrpljenim“ kodom, to je teže dodati nešto novo. Funkcionalnost koja bi u „čistom“ sistemu zahtevala dve nedelje posla sada zahteva šest. Takođe, uticaj tehničkog duga se jasno vidi kada planiramo održavanje sistema u odnosu na implementaciju inovacija – ako sistem „puca“, inženjeri postaju vatrogasci. Svaki sat proveden u rešavanju hitnih bagova na produkciji, padova sistema tokom pika prodaje, jeste sat manje uložen u razvoj inovacija“, naglašava Domazet.
Kao najopasniji segment u ovoj priči on vidi činjenicu da tehnički dug stvara „špageti kod“.
„Kada, na primer, dodamo novi filter na stranici kategorije, odjednom prestane da radi dugme za dodavanje u listu želja. Zbog toga testiranje traje drastično duže, što ponovo pomera datume lansiranja“, pojašnjava Domazet.
Posledice tehničkog duga osećaju i korisnici. Domazet kaže da to može da bude indirektno, ali za potrošače veoma bolno.
„To su oni momenti kada čujete „sajt koči“, a zapravo dolazi do usporenih performansi i latencije. Kada se u pozadini nagomila loš kod, zastarele biblioteke ili neoptimizovani upiti ka bazi podataka, platforma postaje teška i spora“, otkriva Domazet.
Šta korisnik oseća?
„Predugo čekanje da se učita stranica proizvoda, beskrajno okretanje loadera prilikom primene filtera za pretragu. Kupac ne misli „imaju lošu arhitekturu mikroservisa“, već misli „ova aplikacija je užasna“ i napušta vašu stranicu“, upozorava on.
Naglašava da se vremenom javlja poznati sindrom „zastarele platforme“.
„Razlog je i više nego jednostavan – inženjerski tim troši 80 odsto svog vremena boreći se sa tehničkim dugom, održavanje sistema i „gašenje požara“, pa im ostaje vrlo malo kapaciteta za inovacije. Posledica je da korisnik vidi da vaš vebsajt izgleda zapušteno i zastarelo“, ističe Domazet.
Upozorava da, dok se na tržištu pojavljuju aplikacije koje uvode napredne opcije, poput personalizovanih preporuka, i dalje postoje platforme koje mesecima ili godinama nude iste, bazične funkcionalnosti, uz konstantne nepredvidive bagove i veoma upitno korisničko iskustvo.
„Korisnik se, na posletku, oseća frustrirano i nailazi naizgled nelogične greške koje mu direktno urušavaju poverenje. Na primer: proizvod koji je upravo dodat u korpu odjednom nestane. Zato moram posebno da naglasim da je nama u Ananasu, prilikom donošenja svake odluke ili planiranja, apsolutni prioritet korisničko iskustvo. Iskustvo kupovine mora da bude lako, intuitivno i jednostavno, a ono što se dešava u pozadini rešava naš tim“, kaže on.
Jedno od najčešćih pitanja koje Domazet i njegove kolege iz product tima dobijaju glasi: „Pa dobro, zašto ne zaustavimo razvoj na mesec dana i sve to ne sredimo?“.
U realnosti, odgovara, pauziranje razvoja novih funkcionalnosti znači stagnaciju na tržištu i prepuštanje prostora konkurenciji.
Sa druge strane, dodaje, ignorisanje duga znači da će se „platforma vremenom urušiti pod sopstvenom težinom“.
„Kao produkt tim, naš zadatak je da upravljamo ovim balansom. Praksa kojoj težimo u Ananasu jeste da u svakom kvartalu alociramo manji procenat inženjerskih kapaciteta za otplatu tehničkog duga, refaktorisanje i infrastrukturna poboljšanja, dok većina ide na razvoj novih funkcionalnosti koje direktno donose poslovnu vrednost. Na ovaj način osiguravamo da možemo brzo da rastemo, ali i da platforma na kojoj gradimo ostane stabilna i spremna za taj rast“, zaključuje Domazet.