Kako se utjeruje tehnički dug?

Vrlo često možete čuti priče nezadovoljnih programera, jer rade na nekom programskom kodu koji je težak za održavati jer je napisan navrat-nanos. S druge strane imate menadžere koji ganjaju datume i rokove s ciljem da sve bude gotovo što prije kako bi ispunili neki poslovni cilj.

Kako pomiriti te dvije strane i dobiti softver koji je dovoljno kvalitetan, a opet, u nekom razumnom vremenu?

Kredit

Ako vam danas treba 100.000 EUR da kupite stan, i nemate tih 100.000 EUR, onda odete u banku, i podignete kredit koji ćete vraćati idućih 20 godina. Kad prođe 20 godina, uz neku efektivnu kamatnu stopu od recimo 6,10%, ukupno ćete otplatiti oko 170.000 EUR - naravno, zbog kamata.

To vam je u redu, jer time efektivno plaćate cijenu za to što ste kupili stan sada, a ne za 20 god kad bi možda uštedili dovoljno novaca za njega.

Dakle, pod cijenu da nešto imate danas - spremni ste to skuplje platiti.

Tehnički dug

Kad radite na softverskom projektu, određene stvari možete napraviti kvalitetno, ili ih možete napraviti brzo. Svaki put kad žrtvujete kvalitetu zbog brzine - u svoj projekt ste unijeli nešto što se zove tehnički dug (technical debt).

Kad ovdje pričam o "kvaliteti", ne mislim na kvalitetu onoga što korisnik softvera vidi i koristi. Tu mislim na arhitekturu samog rješenja. Ne mislim na to kakva je fasada kuće - mislim na to kakvi su temelji na kojima se ona gradi.

Osnovni utjecaj tehničkog duga na projekt je da on čini softverski projekt težim za održavanje - unošenje novih funkcija traje dulje, i generalno sve sporije ide.

"Samo da radi"

Svaki put kad je netko rekao "Složite to tako - samo da radi!" i nije odabrao arhitekturalno najbolje rješenje - efektivno je tehnički zadužio taj projekt. Podignuti tehnički dug samo po sebi nije nužno problem, problem je ako se taj tehnički dug nikad ne "otplaćuje".

Kako se utjeruje tehnički dug?

Kako kaže onaj vic - isto kao i tehnički kratak!

Ali ozbiljno, tehnički dug se utjeruje refaktoriranjem koda. Refaktoriranje je kad postojeći programski kod interno izmijenite ili napišete opet, ali mu ne mijenjate funkcionalnost ili vanjsko ponašanje (ono što vide krajnji korisnici).

To radite zato da u budućnosti možete lakše održavati taj kod, te da lakše i brže uvodite nove promjene u njemu (tj.da otplaćujete manju "kamatu")

Refaktoriranje je kao pospremanje ormara. Prema van je sve isto - ista odjeća se nalazi u ormaru. Ali, ako je ljepše posložite, lakše ćete idući put pronaći određeni komad odjeće, da se obučete neće vam trebati pola sata, a i nećete morati rasturiti cijeli ormar prilikom toga.

Zašto mnoge organizacije izbjegavaju refaktoriranje?

Ponekad organizacije izbjegavaju refaktoriranje jer ne vide vrijednost u njemu. A često ne vide vrijednost jer refaktoriranje ne donosi nikakav očiti i vidljivi benefit. I prije i nakon refactoringa - aplikacija radi istu stvar, pa zašto onda trošiti vrijeme (=novac) na refaktoriranje?

Razlog zašto morate investirati u refaktoriranje je zato što ako periodički ne otplaćujete taj dug, on vam se samo gomila, razvoj projekta ide sve sporije i sporije, i na kraju - bankrotirat ćete.

Tehnički bankrot

Svaki projekt ima određenu količinu tehničkog duga, to je potpuno normalno i nije problem. Isto kao što nije problem da imate kredit od 1.000kn mjesečno, ako zarađujete 7.000kn. Problem je ako imate 4.000kn kredita, a zarađujete 5.500kn mjesečno.

Kao i u stvarnom svijetu, ako dovoljno dugo gomilate tehnički dug, ući ćete u tehnički bankrot. Tehnički bankrot znači da vjerojatno morate cijelu aplikaciju napisati ispočetka, jer je jednostavno preloše realizirana da bi se išta na njoj radilo, pa čak i da bi je se refaktoriralo.

Ne bi bili ni prvi ni zadnji koji su to morali raditi. Joel Spolsky je davno napisao članak o tome kako je Netscape radio rewrite cijele svoje aplikacije, vrlo vjerojatno zbog nagomilanog ogromnog tehničkog duga. Kao rezultat toga - na kraju su propali. 

Uloga tehničkog menadžera

Definicija tehničkog menadžera za mene je osoba koja na nekom projektu brine o obje strane priče - biznis i tehničkoj strani. To su ljudi koji razumiju kako će se nešto tehnički implementirati, ali razumiju i poslovnu pozadinu projekta.

Takva osoba mora jasno odlučiti kada ulazi u tehnički dug, a kada ne te odlučiti da li je to opravdano ili nije.

Par stvari koje je bitno zapamtiti iz svega ovoga:

  • Podižite tehnički dug stvarno kad morate - ne zadužujte se, ako baš ne morate.
  • U planu razvoja uključite vrijeme za povremeni refactoring - otplaćujte kredit, pomalo, kroz vrijeme. Tipa uključite 10-20% vremena na mjesečnoj razini da radite refaktoring.
  • Donosite informirane odluke - da li je taj rok baš tako jako bitan? Da li je ta funkcionalnost presudna za ovaj release? Ako će nešto unijeti ogromnu količinu tehničkog duga u ovom trenutku - ima li smisla to izbjeći možda u ovoj fazi?
  • Tehnički dug možete minimizirati korištenjem boljih tehnologija, frameworkova i alata koji definiraju najbolje prakse kod razvoja softvera

Po mojem mišljenju, tehnički dug je nešto u što se mora ulaziti kontrolirano i planirano, a ne bez mozga, jer na duge staze može ispasti katastrofa.

Biznis strana će biti nesretna jer ne dobiva nadogradnje funkcionalnosti dovoljnom brzinom i što za neke banalne stvari programerima treba hrpa vremena da implementiraju. S druge strane, programeri će biti nesretni jer se stalno bore s lošom arhitekturom, umjesto da rade kreativan posao.