Tehniline võlg ja tema intressid

Intelligentsed inimesed saavad üldiselt võla ja laenu põhimõttest päris hästi aru – saan praegu palju raha, hiljem maksan rohkem raha tagasi. Ilmselgelt on selline tegevus kõige kasu(m)likum laenu andjale (pangad, eksole:)), kuid teatud tingimustel ka laenajale. Lihtsustatult – laenu on mõtet võtta siis, kui see aitab sul tulevikus rohkem teenida või vähem kulutada.

Tarkvaraarenduses on kasutusel termin tehniline võlg (Wikipedia, Martin Fowler), mis on põhimõtteliselt laen tulevase produktiivsuse/tootlikkusse arvelt. See tähendab, et praegu toodan ühes ajaühikus hästi palju uut funktsionaalsust, hiljem toodan vähem, sest tegelen hoopis varem realiseeritud asjade parandamisega. Võrreldes rahaga on tarkvara tootmise produktiivsus aga suhteline ja mittemõõdetav (Martin Fowler ja technicaldebt.com), mis ajab asja mõnevõrra keerulisemaks. Teatud tingimustel võib produktiivsust ka rahaga mõõta – kui tiim, mis alguses teenis korralikku kasumit muutub pealtnäha põhjuseta vähem kasumlikuks, siis tõenäoliselt võeti millalgi tehnilist laenu (tekkis tehniline võlg) ja nüüd makstakse intresse. Kahjumisse keeramine tähendab, et inkasso tuli ukse taha ka põhiosa välja nõudma.

Tehnilise võla alla käib kõik, mis muudab uute asjade lisamise või süsteemi käigushoidmise järjest kulukamaks/aeglasemaks, näiteks:

Võlg	Intressid
lihtsalt halb kood	koodist arusaamine nõuab suurt pingutust, muutmisel ootamatud regressioonid
ebapiisav kvaliteet	suur osa aega ja energiat läheb vigade parandamisele
sobimatu arhitektuur / suur keerukus	sisemine arhitektuuri ei toeta enam edasi arendamist, väike muudatus nõuab fundamentaalseid muudatusi
build’i ja paigalduse keerukus	uued paigaldused on mitmenädalased ettevõtmised, sest on palju eel- ja järeltingimusi, et süsteem tööle hakkaks
jagamata teadmus	õppimiskõver – mõne süsteemi osa kohta ei tea keegi, kuidas see toimib (Ants teadis, aga ta enam ei tööta meil…)

Ilmselgelt pole see jaotus lõplik ja need kõik omavahel tihedalt seotud, aga soojenduseks käib küll.

Kuidas võlg tekib? Põhjuseid on palju, kuid jagaks need neljaks:

Põhjus	Lühidalt	Kuidas tekib tarkvaramaailmas?	Vaste “päris maailmas”
teadlik risk	investeering – oodatav kasu ületab intresse	lepinguliste kohustuste täitmiseks (leppetrahvid) või turueelise saamiseks (kiire prototüüp)	planeeritud investeeringud
teadmatus	ei teata ega osata paremini	algaja programmeerija teebki imelikke asju	“väikses kirjas tekst” näiteks krediitkaardilepingul
hoolimatus	ei huvita	arendaja, analüütik või testija, kes vaatab ainult oma kitsast pilti – “mina saan oma linnukese kirja, pärast tulgu või veeuputus”	“peaasi, et praegu palju raha on, küll kuidagi tagasi maksan (veel parem – keegi teine maksab)”
tähtajad	lihtsalt on vaja asi kindlaks ajaks ära teha	lepingust tulevad tähtajad või kindla hinnaga tööd	ootamatud väljaminekud või ootamatult vähenenud sissetulekud

Esimene on mõistlik, kuid ei tohi unustada, et võlg on võõra oma ja mida varem tagasi maksta, seda parem (liitintress!).

Teine on väikestes kogustes paratamatu – keegi ei sünni targana. Siia alla käivad ka pisemad hooletusvead. Seda aitavad vältida näiteks koodiülevaatused, staatilised analüsaatorid ja kõige rohkem hariv kirjandus. Enamasti on tegemist probleemiga, mida on üsna lihtne kontrolli all hoida ja ajapikku jääb seda vähemaks.

Kolmas on puhtalt pahatahtlik. Jaole saada aitavad samad meetmed, mis teadmatuse puhulgi, kuid aeg seda viga ei paranda. Kui teil sellised “sõbrad” tööl on, siis ilmselt pole vaenlasi vajagi. Soovitan tõsist südamest- südamesse vestlust või eriala vahetust (näiteks juristiks või poliitikuks).

Neljas on kõige salakavalam ja kõige levinum. Tihtipeale maskeerib ta ennast esimeseks, kuid seejärel “unustatakse” võlg ära ning tulevad juba uued tähtajad. Samuti kiputakse just tähtaegade puhul esimesena ohvriks tooma “mitteproduktiivsed” tegevused nagu koodiülevaatused, refaktoreerimine, automatiseerimine, koolitused jms, mis tekitavad hiilgava võimaluse teisele ja kolmandale kategooriale. Teoorias on vältimine muidugi lihtne – tuleb planeerida realistlikud tähtajad! Praktikas on tarkvaraarenduse täpne planeerimine segu raketiteadusest, peenest psühholoogiast, OCD-st ja nunnudest kassipoegadest. Väikelapsed ja Kettamaailma jumalad tulevad esimesena meelde – planeeri mis sa planeerid, lõpptulemuseks võib vabalt olla ka 42.

Ei, tegelikult saab ka tarkvaraarendust üsna täpselt planeerida ning tulebki. Detailid on juba teine ja hoopis pikem jutt, aga näpunäiteid ikkagi:

• arvesta süsteemi loomulikku riknemist – tarkvara allub termodünaamika teisele seadusele:). Ehk lihtsustatult – et tarkvara oleks sisemiselt korras, tuleb selle nimel pidevalt tegutseda. Siia alla käib refaktoreerimine, arhitektuuri korrastamine, automatiseerimine, samuti dokumentatsiooni ajakohasena hoidmine. See aeg tuleb arendusse sisse planeerida. Kliendile selle aja maha müümine on muidugi kunst.
• pane tähele väikseid märke – kui arenduste kiirus vaikselt kukub või live-toe koormus tõuseb, siis see võib olla märk tehnilisest võlast.
• iga ajaline surve tekitab tehnilist võlga – kui tiim peab tähtajaks tarnima, siis tuleb järgmine tsükkel planeerida väiksema koormusega, sest tuleb maksta intresse ning soovitav oleks ka põhiosa tagasi maksta.
• usalda arendajaid – kui arendaja ütleb, et korralikult tegemine võtab x tundi, siis võtabki (või kauem). Kui survestada lühema aja peale (nt y tundi), siis tuleb see hiljem ümber teha ja aega läheb x-y/2+n tundi, kus n suureneb vastavalt sellele, kui palju hiljem see ümber tehakse.
• kui miski on liiga ilus, et olla tõsi, siis ilmselt nii ongi – kui tundub, et tiim liigub üle ootuste hästi, siis tõenäoliselt võetakse vaikselt kvaliteedi arvelt laenu.
• arvesta liitintresse – hilisem tagasimaksmine on märksa kulukam. Samuti võib võla ignoreerimisel minna pankrotti – ühtegi uut arendust ei ole võimalik teha ilma aeganõudvate parandusteta, kuid selleks ei ole raha/aega.

Lõpetuseks temaatiline laul – Eestimaa on võlgu (parafraseerime – tarkvara on võlgu).

Vaata ka:

• tehnilise võla tsükkel
• Võla sissenõudjad
• Martin Fowler
• technicaldebt.com

---