Tekninen velka: mitä se on ja miten sitä vähennetään

Sovelluksen alussa uuden ominaisuuden lisääminen on nopeaa. Parin vuoden päästä yhtä suuri muutos vie kolme kertaa kauemmin, ja jokaisen julkaisun jälkeen pitää korjata jotain, mihin kukaan ei koskenut. Kehittäjä sanoo ”tätä on vaikea muuttaa”, eikä kukaan osaa tarkalleen selittää, miksi.

Tällä on nimi: tekninen velka. Se on kaikkien niiden oikoteiden summa, jotka joskus tehtiin, jotta jokin saataisiin nopeammin valmiiksi, ja joita ei myöhemmin korjattu. Kuten rahallinen velka, myös tämä kerryttää korkoa: mitä kauemmin se seisoo, sitä kalliimpi on jokainen seuraava muutos.

Mistä tekninen velka syntyy

Tekninen velka ei välttämättä ole huonon työn merkki. Usein se on ollut tietoinen ja järkevä päätös: tuote piti saada markkinoille ennen kilpailijaa, aikataulu oli kiinteä tai ei vielä ollut selvää, mitä käyttäjät oikeasti tarvitsevat. Ongelma syntyy, kun oikotiestä tulee pysyvä ratkaisu.

Yleisimmät lähteet:

• Päivittämättömät komponentit. Sovelluskehys, kirjastot ja palvelinohjelmistot ovat useita versioita jäljessä. Jokainen väliin jäänyt päivitys tekee seuraavasta suuremman ja riskialttiimman.
• Kopioitu koodi. Sama logiikka on viidessä paikassa hieman eri tavalla. Korjaus yhdessä paikassa ei päädy muihin.
• Puuttuvat testit. Kukaan ei voi ennen julkaisua tarkistaa, rikkoiko muutos jotain muualla.
• Dokumentoimattomat päätökset. Miksi tämä taulu on rakennettu näin? Miksi tämä funktio kutsuu kolmea muuta? Vastaus lähti kehittäjän mukana.
• Väliaikaiset ratkaisut. ”Tehdään nyt näin, korjataan myöhemmin.” Myöhemmin ei koskaan tullut.

Miten teknisen velan tunnistaa

Koodia ei tarvitse lukea itse huomatakseen velan. Liiketoiminnan oireet ovat usein selvempiä:

• Arviot venyvät: ”tämä vie kaksi viikkoa” muuttuu kuudeksi.
• Vikoja tulee lisää nopeammin kuin niitä korjataan.
• Uusi kehittäjä tarvitsee kuukausia, ennen kuin uskaltaa muuttaa mitään.
• Tiettyyn järjestelmän osaan kukaan ei halua koskea.
• Tietoturvapäivityksiä ei asenneta, koska ”se voi rikkoa jotain”.

Jos kolme tai useampi näistä pitää paikkansa, velka on todennäköisesti jo suurempi kuin uuden kehityksen budjetti.

Miten velkaa mitataan

Teknistä velkaa ei voi laskea tarkasti euroina, mutta sen voi kartoittaa. Katselmuksessa käyn läpi:

1. Komponenttien iän. Mitkä sovelluskehykset ja kirjastot ovat vailla tukea ja missä on tunnettuja tietoturva-aukkoja.
2. Riskikohdat. Ne osat, joissa muutokset aiheuttavat eniten vikoja ja joita muutetaan useimmin. Niissä korjaaminen kannattaa eniten.
3. Riippuvuudet. Mikä kutsuu mitä ja vaatiiko yhden osan vaihtaminen kymmenen muun muuttamista.
4. Testien ja dokumentaation tilan. Kuinka suuri osa järjestelmästä on tarkistettavissa ilman käsin klikkailua.

Tuloksena on luettelo, jossa jokaisen ongelman kohdalla on riski, vaikutus ja arvioitu työmäärä. Sen perusteella voi päättää, mitä tehdään heti ja mikä voi odottaa. Miten katselmus tarkemmin etenee, on kerrottu kirjoituksessa ohjelmistoauditointi.

Miten velkaa vähennetään pysäyttämättä liiketoimintaa

Yleisin virhe on päättää, että ”kirjoitetaan koko juttu uudelleen”. Toimiva järjestelmä sisältää vuosien aikana kertyneitä liiketoimintasääntöjä, joita yksikään määrittely ei kuvaa. Uudelleenkirjoituksessa ne kaikki pitää löytää uudelleen, ja sillä välin vanhan järjestelmän pitää edelleen toimia. Milloin uudelleenkirjoitus silti kannattaa, kerron kirjoituksessa vanha ohjelmisto: modernisoida vai rakentaa uudelleen.

Järkevämpää on edetä vaiheittain:

• Aloita tietoturvasta. Tuettomat komponentit ja tunnetut tietoturva-aukot ennen kaikkea muuta.
• Korjaa siellä, missä parhaillaan työskentelet. Jos uusi ominaisuus koskee jotain moduulia, siisti moduuli samalla. Näin velka vähenee siellä, missä se oikeasti maksaa.
• Lisää testit ennen muuttamista. Riskialttiin osan ympärille ensin testit, sitten muutos. Näin näkee heti, jos jokin meni rikki.
• Vaihda osa kerrallaan. Vanha moduuli korvataan uudella, kunnes kaikki osat on vaihdettu. Jokaisen askeleen jälkeen sinulla on toimiva sovellus.
• Dokumentoi samalla. Jokainen päätös ylös, jotta seuraavan ihmisen ei tarvitse aloittaa alusta.

Kuinka paljon aikaa velan vähentämiseen kannattaa antaa

Hyvä nyrkkisääntö on varata osa jokaisen kehityssyklin ajasta siivoamiseen sen sijaan, että siitä tehdään ”joskus myöhemmin” -projekti. Jos velka on jo niin suuri, ettei uusia ominaisuuksia voi lisätä kohtuullisessa ajassa, tarvitaan erillinen modernisointivaihe. Silloin pitää jonkin aikaa tehdä enemmän siivoamista kuin uutta kehitystä.

Yhteenveto

Tekninen velka on normaalia, mutta se ei saa kasvaa näkymättömästi. Kartoita se, aloita suurimman riskin osista ja vähennä sitä askel kerrallaan niin, ettei liiketoiminnan tarvitse odottaa.

Jos sovelluksesi on tullut pisteeseen, jossa jokainen muutos on kallis ja riskialtis, katso, miten teen ohjelmistojen modernisointia ja jatkokehitystä, tai kuvaile tilanteesi. Sanon rehellisesti, kannattaako sovellusta siistiä vai onko järkevämpää rakentaa jotain uutta.