Teknistä velkaa on kaikkialla IT-maailmassa ja se on erottamaton osa ohjelmistokehitystä. Voidaksemme kunnolla puhua teknisestä velasta, meidän kannattaa kuitenkin ensin määritellä, mitä sillä tarkoitetaan.
Mikäli teknisen velan käsitettä lähdetään määrittelemään puhtaasti velka-analogian kautta, selkein olisi “Oikopolku, joka helpottaa kehitystä lyhyellä aikavälillä, mutta josta syntyy kustannuksia pitkällä aikavälillä”. Velka maksetaan takaisin refaktoroimalla ja korko on se kustannus, joka aiheutuu velan olemassaolosta.
Hyvin tyypillinen syy teknisen velan ottamiselle on aikataulupaine julkaisun lähestyessä. Uusi toiminnallisuus voidaan esimerkiksi toteuttaa lisäämällä poikkeuslogiikkaa suoraan olemassa olevaan koodiin, vaikka se olisi ristiriidassa ohjelmiston arkkitehtuurin kanssa. Käytännössä tämä voisi tarkoittaa vaikkapa sitä, että yhteen sovellukseen lisätään yhtä käyttäjää varten erikoissääntö, vaikka logiikka kuuluisi koko alustan käyttöoikeuksia hallinnoivaan palveluun.
Teknisen velan korko
Teknisen velan määrää järjestelmässä voidaan vielä melko helposti arvioida, mutta korko on ilmiönä monimutkaisempi. Yleisesti teknisen velan ajatellaan tarkoittavan lähinnä sekavaa koodia ja koron taas tästä johtuvaa kasvanutta kehityskustannusta. Korko ei kuitenkaan rajoitu vain hidastuneeseen kehitykseen, vaan velan luonteesta riippuen sen ilmenemistavat voivat olla hyvinkin monimuotoisia.
Muutamia esimerkkejä velasta ja korosta edellisistä projekteista:
- Valittu kirjasto ei tue kaikkia tarvittavia käyttötapauksia
- Hidas algoritmi lisää web-ohjelman latenssia
- Puutteellinen testaus näkyy lisääntyneinä bugeina
- Huonosti optimoidut kyselyt vaativat tarpeettoman kalliin datainfrastruktuurin
- Monimutkainen koodipohja vaikeuttaa uusien kehittäjien onboardausta
Kaikki velasta aiheutuva ylimääräinen kustannus ja haitta on siis korkoa.
Milloin velka kannattaa?
Kannattaako siis vältellä korkoa viimeiseen asti ja tavoitella täysin velatonta järjestelmää? Ei välttämättä. Yksi rahavelan ja teknisen velan suurimpia eroja lienee se, että teknistä velkaa tai sen korkoa ei välttämättä tarvitse maksaa takaisin: kun ohjelmisto poistuu käytöstä, poistuu myös siihen liittyvä velka. Ja jos vaikkapa edellä mainitun huonosti optimoidun algoritmin hitaus ei aiheutakaan mitään konkreettista haittaa, korko jää lähinnä teoreettiseksi.
Teknistä velkaa otettaessa on siis punnittava muutamaa asiaa:
- Paljonko velan ottaminen säästää aikaa?
- Mikä on velasta aiheutuva korko?
- Mikä on velasta aiheutuva refaktoroinnin kustannus?
Koron ja refaktoroinnin tarpeen tarkka ennustaminen on tietysti hankalaa, mutta ainakin teoriassa velkaa on syytä ottaa, jos sen kustannukset eivät koskaan ylitä siitä saatuja hyötyjä. Käytöstä poistuvassa ohjelmistossa kannattaakin siis olla paljon maltillisen koron velkaa, jonka ottaminen on tuonut säästöjä ohjelmiston elinkaaren aikaisemmissa vaiheissa.
Loppusanat
Todellisuus ei kuitenkaan koskaan ole yhtä ruusuinen kuin oppikirjaesimerkit, ja usein velkaa syntyy hallitsemattomasti ja ilman kunnollista suunnittelua. Vaikka ihannetapauksessa velka katoaa ohjelmiston käytöstä poistumisen sivuvaikutuksena, monesti velka saattaa olla syy hankkiutua eroon koko ohjelmistosta.
