Tekninen velka voi johtaa konkurssiin
Tekninen velka tarkoittaa ohjelmiston kehityksessä syntyvää toteutusvelkaa. Joskus on perusteltua tehdä jokin ominaisuus nopeasti (quick and dirty) tiedostaen, että oikominen johtaa tulevaisuudessa lisätyöhön ominaisuuden muuttamisen tai ylläpitämisen suhteen.
Tekninen velka syntyy, kun ei ole mahdollisuutta, aikaa tai kykyä investoida työtä jonkun asian tekemiseen kestävällä tavalla. Kuten taloudelliseen velkaan, myös tekniseen velkaan liittyy korko. Korko on se lisätyö, joka joudutaan laittamaan sen asian jatkokehittämiseen, jonka tekemisessä alunperin oiottiin.
Velkaa voidaan poistaa investoimalla kehitykseen myöhemmin, eli teknisen velan korkoa voidaan pienentää poistamalla huono ratkaisumalli. Korkoja voidaan toisaalta maksaa, jos korkotaso pysyy matalana ja velan poiston vaatima investoinnin hinta on korkea. Huonoimmassa tapauksessa velka kasvaa koko ajan, samoin korko, ja lopulta edessä on konkurssi – koko ohjelmiston uudelleenkirjoitus.
Teknisen velan ajatus on kohtuullisen yksinkertainen ja havainnollistava, mutta sen mittaaminen on hankalaa. SonarQube:lla on tähän mittari, jolla mittaaminen ei kuitenkaan ole ongelmatonta: mittarin osoittamat työmäärät velan poistamiseksi ovat noin 14-kertaiset testattaessa toteutuneisiin työmääriin nähden (testattu yksittäisessä projektissa). Ansioistaan huolimatta SonarQube ei myöskään arvioi perusteellisesti suunnittelun ja arkkitehtuurin velkaa, mikä edellyttäisi sekä asioiden arvioimista kokonaisuuksina että sisällön ymmärtämistä. SonarQube arvioi tehokkaasti yksittäisiä tiedostoja ja niiden formaaleja ominaisuuksia, mutta sisällön ymmärtämiseen tarvitaan ihmistä.
Sekä teknisen velan syntymiseen että koodin laatuun voi koodaaja vaikuttaa itse: teknisen velan syntyminen vahingossa ja huomaamatta pitää estää, ja työkalujen lisäksi tärkeimmät aseet siihen ovat ongelman tiedostaminen ja oikea toimintamalli.
Teknisellä velalla on suora (joskin käänteinen) yhteys laatuun ja laadunvarmistukseen: mitä suurempi tekninen velka, sitä heikompi laatu ja laadunvarmistus. Johdatuksen aiheeseen saat lukemalla esimerkiksi lopussa olevia lähteitä.
Takaisin otsikkoon: tarvitseeko velka maksaa takaisin? Pandemian ja siihen liittyvän keskuspankkielvytyksen myötä esitetty kysymys nousi esiin poliittiselta taholta, mutta sai varovaista vastakaikua myös talousasiantuntijoilta. Ehkä taloudellista velkaa on järjestelmän uskottavuuden nimissä pidettävä takaisinmaksettavana, mutta taloudellinen velka on validi vain niin kauan kuin velallinen on olemassa.
Myös tekninen velka raukeaa, kun ohjelmistosta aika jättää. Ohjelmiston elinkaaren pituus on joskus vaikeasti hahmotettavissa, ja väliaikaiseksi ajateltu ratkaisu voi osoittautua kovin sitkeähenkiseksi, kun taas hartaudella rakennettu ohjelmisto ei välttämättä koskaan näe tuotannon käynnistystä. Herääkin kysymys: kannattaako laatuun panostaa lainkaan? Kyllä kannattaa, sillä laadun rakentaminen kehityksen yhteydessä ei tuo lisätyötä verrattaessa laaduttomuuteen, johon palaa helposti enemmän aikaa kerrannaisvaikutuksina. Olennaista on laadun syntyminen tekemisen pisteessä – ei testauspisteessä.
http://martinfowler.com/bliki/TechnicalDebt.html
https://en.wikipedia.org/wiki/Technical_debt
http://www.agiledeveloper.com/presentations/caring_about_code_quality.pdf
