Tehnički dug značajno usporava razvoj softvera i ako mu dozvolimo da izmakne kontroli, svi gubimo: razvoj novih feature-a traje duže, bug-ovi se pojavljuju, a sami programeri će se osećati bespomoćno, radeći na složenom i komplikovanom kodu, čiji se dizajn razlikuje od realnih potreba korisnika.
Uprkos opštem verovanju, tehnički dug ne znači kod lošeg kvaliteta. Loš kod je često toliko kompleksan, da svi imaju poteškoća da ga razumeju, menjaju i održavaju bez da ga pokvare. Dave Farley kaže da je kvalitet koda mera, koja kaže koliko lako možemo isti da menjamo. Uncle Bob (Robert C. Martin) kaže da je profesionalna obaveza i stvar dobrog zanatstva (craftsmanship) pisati čist kod (clean code).
Ako tehnički dug nije problem kvaliteta koda (barem iz tehničkog ugla), zašto nam je on problem? Da li je tehnički dug uopšte problem? Da bismo odgovorili na ova pitanja, moramo da posmatramo kontekst i (planirani) životni vek našeg rešenja. Primera radi, za jedan studentski projekat na fakultetu opravdano je imati rešenje koji ima tehnički dug, s obzirom da taj projekat nakon položenog ispita neće biti dalje eksploatisan, niti će mu se zahtevi menjati ili dopunjavati kasnije. Drugim rečima, otići će u zaborav. Za razliku od studentskih projekata, poslovne aplikacije su namenjene da rade nekoliko decenija, zahtevaju migraciju na noviji hardver, nove operativne sisteme. U poslednjoj deceniji smo svedoci pomeranja značajnog dela enterprise aplikacija sa on-premises na cloud. Visoki stepen tehničkog duga mogu skroz da onemoguće izvršenje gore pomenutih transformativnih promena, te je u enterprise softveru i te kako bitno držati tehnički dug pod kontrolom.
Zašto „samo“ pod kontrolom? Zato što svaki napisani softver može da se poboljša. Svaki novi zahtev može da zahteva promenu osnovnih odluka u inicijalnom dizajnu rešenja. Dodatni napor koji „priprema teren“ za implementaciju takvog novog zahteva je refaktorisanje (proces poboljšanja postojećeg koda). Ali kada refaktorisati i kada nastaviti sa radom?
Na PowerIT konferenciji (gde smo kroz igru učili o tehničkom dugu), 11. oktobra smo u okviru radionice „Dilema tehničkog duga“ simulirali tri različita scenarija upravljanja tehničkim dugom kroz društvenu igru. Postavili smo cilj da naučimo više o tome kada, kako i koliko utiče tehnički dug na produktivnost jedne izmišljene kompanije. Backlog, svima isti, je bio sačinjen od feature kartica, koje su sadržale koliko „taskova“ treba da se uradi da bi se feature završio. Timovi/igrači su simulirali rad na tim feature-ima bacanjem dve kockice. Za svaki feature bili su označeni koji brojevi na kockici su se smatrali urađenim taskom, a koji su bili „blokirani“, tj. nisu doprineli rešavanju. U slučaju da se na obe kockice pojavio isti broj, desio se tehnički dug, i tim je morao da jedan od „slobodnih“ brojeva označi tehničkim dugom, čime su povećali vreme rada. Otplata tehničkog duga je bila moguća ako se u zbiru baci 9 ili više, uz prethodnu najavu.
Krenuli smo sa scenarijom „startap kompanije“, kojoj je izuzetno važno da što pre izađe na tržište sa novim rešenjem, pribavlja klijente i ostvaruje svoje prve finansijske uspehe. Ono što je bilo karakteristično za ovaj scenario, da je rešavanje nagomilovanog tehničkog duga došao na red tek kada nije moglo da se nastavi rad na feature-ima.
Drugi scenario smo nazvali „oprezan pristup“, gde smo želeli da napravimo idealnu tehničku kompaniju koja savršeno prati sve dobre prakse i teži tehničkoj savršenosti. U ovom scenariju se tehnički dug odmah otplatio nakon njegovog nastajanja.
Treći scenario je bio bez ograničenja, i pustili smo timove/igrače da sami izađu sa najboljom strategijom na osnovu stvari što su zaključili i naučili u prethodne dve igre.
Na slici se vide agregirani rezultati tri strategije sa simulacije, startap kompanija u plavoj, oprezan pristup u crvenoj, bez ograničenja u žutoj boji, a tim sa najboljim individualnim rezultatom u zelenoj boji. Ako bolje pogledamo agregirane rezultate, timovi ako nemaju neko pravilo za rešavanje tehničkog duga su skoro sve vreme podbacuju od ostalih strategija. Kako je to moguće?
Tehnički dug je prečica ka korisnicima
Ako bi Vas neko pitao, da li bi izašli danas na tržište sa softverom koji radi malo sporije, ima neka ograničenja u funkcionalnostima ili za dva meseca sa savršenim rešenjem, šta biste izabrali? Šta biste izabrali ako bi rekli da postoji konkurentna aplikacija koja je slična vašoj i release-uje se za tri nedelje?
Ako biste izašli na tržište odmah, da biste iskoristili tri nedelje prisustva na tržištu za osvajanje većeg udela, zapravo ste uveli veliki tehnički dug. Ali isto tako bitno, dobili biste i prve komentare za softver, i mogli ste na njih da odgovorite, da korisnici vide da vi brinete o njima, i stekli bolju reputaciju.
Tehnički dug u trenutku nastajanja je pokazao na poslovnu odluku, da se na neki način kupi vreme da bi se brže izašlo na tržište sa suboptimalnim rešenjem, radi sticanja prednosti i prikupljanja mišljenja potencijalnih kupaca. Ward Cunningham je 1990 godine skovao izraz tehnički dug na sledeći način:
“Isporuka koda ’isprve’ je nalik uzimanja kredita. Taj mali dug ubrzava razvoj sve dok refaktorisanjem isti nije brzo otplaćen. Opasnost leži u tome, ako taj dug ne otplatimo. Svaki minut koji potrošimo radeći na kodu koji nije pogodan za trenutni zadatak, računa se kao kamata na taj dug.”
Ako pogledamo softver koji je već zastupan na tržištu i uvodi se nova funkcionalnost, treba ga postepeno uvesti, pratiti adopciju, i komentare korisnika. Ovo će u velikoj meri povećati ukupan tehnički dug, ali u slučaju dobre adopcije tim će rešavati tehnički dug i poboljšati funkcionalnost postepeno, bez značajnog nezadovoljstva korisnika. U suprotnom slučaju, kada je nova funkcionalnost promašena, lakše je prekinuti rad na njemu ili okrenuti se drugačijem pristupu, pošto su ulozi još mali.
Isti scenario možemo da posmatramo iz drugog ugla, da je nova funkcionalnost urađena do savršenstva, sa dva meseca kašnjenja od konkurencije. Konkurencija je ubrzo shvatila da je njihov inicijalni pristup bio loš i već su okrenuli ka drugačijem rešenju, a Vi i dalje radite na istom rešenju koje je vaša konkurencija već napustila. Upravo se tu nastaju problemi: uloženo je dva meseca više sredstava i vremena u rešenje koje niko neće, konkurencija je već probala to i okrenula se drugom pristupu i dalje osvaja tržište.
Tehnički dug je moćan alat
Iako tehnički ljudi gledaju tehnički dug kao neopipljivo zlo u softveru, ona je u stvari vrlo moćan alat u razvoju softvera. Omogućava eksperimentisanje, kontrolu troškova, uticaj na tržišni udeo, i ako se koristi na pravi način: da se tehnički dug drži pod kontrolom, da se blagovremeno i postepeno smanjuje, može da uzdigne kompaniju. Ali ako se stalno okrenemo ka uvođenju tehničkog duga, težina duga će postepeno, ali sigurno usporiti razvoj dok se isti ne slomi pod pritiskom. Na nama je da nađemo pravi balans između uzimanja i otplate tehničkog duga da bismo mogli sa ponosom da gledamo u naša rešenja i nakon nekoliko decenija.