Ohjelmistoprojektin 7 kuolemansyntiä – 5. osa: kaikki muu paitsi välitön bisneshyöty on turhaa

Älä lankea softaprojektin kuolemansynteihin! Viidennessä synnissä palaamme koodin alkulähteille: miksi koodikantaa pitäisi ronkkia, jos sillä ei ole suoraa vaikutusta liiketoimintaan? Kansa vaatii uusia featureita!

Uskomus:

Vain välittömällä bisneshyödyllä on väliä.

Totuus:

Myös koodikannan laadulla on väliä! Mitä pahemmin koodikanta mätänee, sitä hankalampi on tehdä mitään liiketoiminnalle hyödyllisiä muutoksia. Jos softaan kertyy liikaa teknistä velkaa, joudutaan tilapäisiin korjailuihin kaatamaan yhä enemmän rahaa. Tällöin bisneksenkin kehitys vääjäämättä hidastuu.

Sehän toimii jo

Softaprojektin sudenkuoppia ruotiessa on aiemminkin mainittu, että projekti nopeutuu, kun koodikanta on kunnossa. Höttökoodi hidastaa devaamista ja lisää tietoturvariskejä, karkottaa tekijän toisensa perään ja sitä myötä kasvattaa kuluja.

Tyypillinen jännite monissa ohjelmistoprojekteissa on, että koodaajat valittavat koodikannan homeisuutta ja pyytävät resursseja sen parantamiseen, kun taas johtoporras evää pyynnöt ja käskee tekemään lisää uusia ominaisuuksia – onhan se ainoa asia, josta asiakkaat maksavat (oikeasti asiakkaat eivät maksa kilkuttimista vaan siitä, että kilkuttimet toimivat).

Lopputulemana koodaajat pitävät managereita tekniikasta tietämättöminä ja managerit taas koodareita valittavina hienohelmoina, joiden suurin mielenkiinnon kohde on detaljien kiillotus oikeiden töiden tekemisen sijaan.

Koodin laadulla on välitön ja jopa dramaattinen vaikutus työn tehokkuuteen. Miltei jokainen devaaja on ollut tilanteessa, jossa vartin koodaushomma kestää koodikannan pääsiäismunien takia monta päivää. Tästä huolimatta saatetaan vaatia, että mitään parannuksia olemassa olevaan koodiin ei saa tehdä, koska "sehän toimii jo" ja "siitä ei ole välitöntä bisneshyötyä".

Toki joskus voi olla “getting shit done, fast” -tilanne ja tuotteen markkinapotentiaali olisi pitänyt selvittää jo eilen. Jos tuote lähtee lentoon, tehdään sen jälkeen homma alusta asti kunnolla. Tällöin tuotekehityksen johdossa pitää olla kovapäinen tyyppi, joka uskoo asiaansa, jotta protovaiheen jälkeen ei rakenneta vain hätäisiä purkkafiksejä.

Konsultti, tuu pyyhkimään!

Välittömän bisneshyödyn kaikkivoipaisuus on jostain syystä pesiytynyt erityisen syvälle ATK-alalle, ja sen alttarille uhratulla koodin laadulla on monia epäsuoria varjopuolia. Näistä ehkä vakavin on se, että tällainen työpaikka on urakehityksen kuolemanselli.

Jos työ on epämukavaa eikä uutta saa oppia tai työoloja parantaa, ei kukaan eturivin kehittäjä jää sitä katselemaan. Vanhat synnit lukitsevat tekemään kaiken vaikeamman kautta ja hitaasti, joten perusparannuskustannuksetkin nousevat. Tällöin yhä suurempi osa päivittäisestä työstä on tarpeettoman monimutkaisuuden kanssa painimista – samalla kun muu maailma ja tekniikan kehitys juoksevat eteenpäin. Hyvällä koodikannalla tuskin saa houkuteltua osaavia tekijöitä taloon, mutta huono koodikanta on varmin tapa hätistellä ne sieltä pois.

Jos hyvä devaaja ei saa tehdä kunnon työtä, tarvitaan huippudevaaja purkamaan ongelma. Silloin voidaan turvautua konsulttiin. Parhaat kehittäjät eivät pelkää tarttua epätäydelliseenkään koodiin: rakettitieteilijät auttavat myös teknisen velan pienentämisessä.

Katastrofiprojektitkin (tai ainakin osa-aikaiset katastrofit) kuuluvat konsulttityöhön, ja näidenkin hoitaminen kunnialla on rakettitieteilijöiden vahvuuksia. Tosin konsulttejakin houkutellaan parhaiten kauniisti kukkivan ja hyvin lannoitetun koodikannan medellä.