Design-velka

Ohjelmiston sisäinen laatu on tärkeää, koska se vaikuttaa suoraan ohjelmiston jatkokehityskustannuksiin. Ohjelmiston hyvä design tuottaa säästöjä pienissäkin kehitysprojekteissa. Design-velka (engl. design debt) tarkoittaa tulevia ohjelmiston kehityskustannuksia, jotka johtuvat ohjelmiston huonosta rakenteesta.

Design-velkaa kertyy esimerkiksi tilanteissa, joissa ohjelmistoon halutaan pikaisesti lisäominaisuus. Uuden toiminnon toteuttamistapoja tutkiessa paljastuu, että se vaatisi suuria muutoksia olemassaolevaan lähdekoodiin ja tietokannan rakenteeseen. Yksittäisen lisäominaisuuden takia ei kuitenkaan haluta tehdä suurta lisätyötä, joten keksitään kiertotie, jolla ominaisuuden saa toteutettua. Tämä voi tarkoittaa esimerkiksi lähdekoodin kopioimista pienin muutoksin uutta käyttötarkoitusta varten. Uuden ominaisuuden toteutus tapahtuu tällöin ohjelmiston rakenteen kustannuksella eli ottamalla design-velkaa, sillä nyt ohjelmistoon myöhemmin tehtävät muutokset ovat kalliimpia kuin ne olisivat olleet toimimalla toisin. Tulevaisuuden kehityskustannusten kannalta olisi ollut järkevämpää pilkkoa olemassaoleva koodi ja käyttää uuden ominaisuuden tekemiseen näin syntyviä uudelleenkäytettäviä osia.

Halvin vaihtoehto voi olla kallein

Ohjelmoijat ja projektipäällikkö tai asiakas väittelevät usein työmäärältään eroavien ratkaisutapojen järkevyydestä. Usein kysymys on tilanteesta, jossa valitaan kalliimman toteutustavan ja design-velan ottamisen välillä. Ohjelmoija esittää elegantimman, suuritöisemmän ratkaisutavan sekä mutkia oikovan, nopeamman vaihtoehdon. Jos nopeampi vaihtoehto merkitsee design-velan ottamista, sen todellinen kokonaiskustannus pitkäikäisessä ohjelmistossa on kuitenkin korkeampi kuin velattoman vaihtoehdon. Design-velan "korot" muodostuvat ohjelmiston mätänemisoireiden takia kasvaneista jatkokehityskustannuksista ja näiden kerrannaisvaikutuksista (ks. sivupalkki).

Ohjelmistot kehitetään usein projekteina. Yksittäisen projektin näkökulmasta design-velan ottaminen voi houkutella, jotta pysytään aikataulussa ja budjetissa. Usein velkaa kertyy erityisesti projektin, osaprojektin tai iteraation loppurutistuksessa. Mikäli ohjelmistoa kehitetään tai myöhemmin esiin tulevia virheitä korjataan vielä projektin jälkeen, aiemmin hankittu velka lankeaa siinä yhteydessä maksettavaksi. Lyhyen ja pitkän tähtäimen tavoitteiden välisen ristiriidan ratkaisemiseksi tarvitaan it-ostamisen osaamista. On myös huomattava, että jo yksittäisen iteraation sisällä design-velan korot saattavat syödä velkaa ottamalla saadun hyödyn.

Designin korjaaminen kannattaa

Tehokkain tapa hallita design-velkaa on pyrkiä parantamaan ohjelmiston designia jatkuvasti, aina muutoksia ja korjauksia tehdessä. Jos velkaa on päässyt tietoisesti tai tiedostamatta kertymään, se kannattaa maksaa ajoissa pois, jotta korkoa ei ehdi kertyä liikaa. Yleensä designin parantaminen on tehokkainta tehdä toiminnallisten muutosten tai virheenkorjauksen yhteydessä.

Tilanne voi myös olla niin huono, että siivoustalkoille pitää varata erikseen aikaa. Kattavat, automaattiset regressiotestit helpottavat merkittävästi designin parantamista. Niillä voidaan helposti varmistaa ohjelmiston toimivuus myös refaktoroinnin tai muiden siivoustoimenpiteiden jälkeen.

Design-velan ottaminen johtaa pahimmillaan siihen, että ohjelmisto ajautuu täysin jatkokehityskelvottomaksi. Tällöin ainoalta järkevältä vaihtoehdolta saattaa vaikuttaa kokonaan uuden, korvaavan ohjelmiston tekeminen. Tällaiset korvausprojektit ovat erittäin kalliita ja riskialttiita. Vanha ohjelmisto joudutaan usein pitämään käytössä koko pitkän korjausprojektin ajan. Tänä aikana ohjelmistoon tarvittavat muutokset joudutaan tekemään kumpaankin toteutukseen. Jos korvaavallekin ohjelmistolle pääsee kertymään liikaa velkaa, ajaudutaan pahimmillaan vuosia kestävään uudelleenkirjoituskierteeseen.

Velan hallinta on vaikeaa, koska design-velka ei ole lainkaan niin yksikäsitteinen ja helposti mitattava kuin rahallinen velka. Designin hyvyyttä voi mitata objektiivisesti korkeintaan pieniltä osin, esimerkiksi modulien välisiä riippuvuuksia laskemalla, mutta käytännössä ohjelmiston teknisen laadun arvioinnissa on aina subjektiivinen osa. Ja vaikka täydellisestä designistä päästäisiin tiimissä yhteisymmärrykseen, siihen pyrkiessä tehtävän työn rajahyöty (engl. marginal utility) vääjäämättä laskee, joten designiakin tulee parantaa vain siihen asti kuin se on kustannustehokasta.

Joissakin tilanteissa hallittu design-velan ottaminen voi olla järkevää. Esimerkiksi messuille, tuotelanseeraukseen tai ennen lomakautta saatetaan tarvita käyttöön uusi versio ohjelmistosta. Tällöin on tiedostettava, että jos ohjelmisto pysyy käytössä, ja siihen tehdään korjauksia tai muutoksia, velan korot tulevat siinä yhteydessä maksettaviksi. Pohjimmiltaan design-velan hallinnassa on kyse riskienhallinnasta ja valintojen nostamisesta tietoiseen harkintaan.

Timo Rantalaiho, vanhempi ohjelmistoarkkitehti

Timo Rantalaiho on kokenut ohjelmistosuunnittelija, joka on erikoistunut haastavien tietojärjestelmien kehitykseen ja ns. legacy-koodin kanssa työskentelyyn.