Mitä se koodi lopulta maksaa? Viimeisen 15 vuoden ajalta löytyy paljonkin hyviä ja omasta kokemuksesta uskottavia tutkimuksia ja arvioita huonon koodin vaikutuksista kustannuksiin. Tuoreimmasta päästä on teknologiayhtiö Stripe:n ja Harris Insights and Analyticsin arvio, jossa keskimäärin koodari käyttää 42% ajastaan teknisen velkaan ja ylläpitohaasteisiin. Siis alle 60% työajasta ollaan tuottamassa sitä, mitä tultiin alun perin tekemään. Ja 59% koodareista oli sitä mieltä, että yritykset käyttävät mielettömän määrän rahaa huonon koodin kanssa taisteluun. 79% koodareista koki ettei heille annettu riittävästi aikaa hyvän koodin tuottamiseen. Tutkimuksen mukaan yritykset käyttävät vuositasolla jopa 300 miljardia dollaria vanhan koodin ja palvelun ylläpitoon - pelkästään 85 miljardia dollaria huonon koodin korjaamiseen.
Usein softaprojekteissa keskitytään saamaan tuote tai palvelu tuotantoon aikataulussa ja toimivana. Siis toimivana mutta ei luotettavana? Riittääkö, että palvelu toimii mutta sen laatu on niin heikko, että ylläpito, jatkokehitys ja normaali käyttö vaatii suuren summan rahaa, joista ei niin sanotusti ollut mitään puhetta kun softaa tilattiin. Ongelma on kokonaisvaltainen eikä johdu huonoista koodareista, osaamattomista asiakkaista tai epäpätevästä projektipäälliköstä. Softa on tiimityötä ja silloin kommunikaation pitää toimia ja luottamuksen olla kunnossa.
Tarina
Suositun vaatekaupan uusi verkkokauppaprojekti oli toteutettu ketterin menetelmin, pysyttiin aikataulussa ja palvelu saatiin käyttöön budjetissa. Tilaaja, tuotantotiimi, asiakkaat olivat tyytyväisiä. Hetken. Palvelun julkaisun jälkeen jo seuraavana päivänä huomattiin useampia ongelmia, osa tuotteista ei löytynytkään kaupasta, joitain tuotteita ei pystynyt lisäämään ostoskoriin, kuluttajat rynnivät paikalle iltaisin eikä kauppa kestänyt ryntäystä ja osa ostoista kaatui epäonnistuneisiin maksutapahtumiin.
Ongelmia lähdettiin selvittämään kaupan toteuttaneen tiimin kanssa. Kesti 4 viikkoa korjata kaikki ongelmat. Laskettiin, että pelkästään epäonnistuneita maksutapahtumia oli 10% kaikista yrityksistä (0,1*200) päivässä. Noin 15% laajasta tuotekatalogista ei löytynytkään kaupasta (150 artikkelia), kauppa kaatui ensimmäisen viikon aikana 3 kertaa keskeyttäen keskimäärin 20 ostotapahtumaa. Myynti jouduttiin keskeyttämään kokonaan kahdeksi päiväksi kun korjattu kauppa julkaistiin uudelleen.
Seuraaviin ongelmiin jouduttiin, kun kauppaa ruvettiin jatkokehittämään ja uusia ominaisuuksia kuten parannettu haku, uusia maksutapoja, kaupan ulkoasua ja tuotehallintapaneelia parannettin. Osa kehittäjistä toimittajan tiimissä vaihtui eikä uudet koodarit tunteneet koodia. Kehittäjillä oli käytössään puutteellinen dokumentaatio ja heikosti kommentoitu koodi. Tuotettu koodi oli monimutkaista ja sen lukemiseen ja yksinkertaistenkin ongelmien selvittelyyn kului 30% työajasta. Koodin refaktorointiin, parempaan luettavuuteen ja parempaan suorituskykyyn, käytettiin keskimäärin 40% ajasta. Uusia ominaisuuksia pystyttiin siis toteuttamaan vain 30%:lla käytössä olleesta ajasta. Jatkokehitys kesti 4 viikkoa.
Kun lopulta päästiin tilanteeseen, että pahimmat ongelmat oli saatu ratkaistua, uusi versio kaupasta julkaistua asiakkaille ja myynti alkoi luistamaan, jouduttiin solmimaan ylläpitosopimus uuden kumppanin kanssa. Tähän johti se, ettei palvelu vieläkään toiminut aina luotettavasti, vaan ylläpitoon palkattu tiimi joutui edelleen korjailemaan virheitä niin koodissa kuin ostotapahtumissa. Ylläpitäjät joutuivat käynnistelemään kaupan uudelleen palvelimilla tuntemattomista syistä tapahtuneista järjestelmän kaatumisista johtuen.
Mitä olisi voitu tehdä toisin?
Ohjelmistotuotannon laatuun vaikuttaa lähes kaikki toteutuksessa tehtävät päätökset. Valitaanko oikeat työkalut tuotantoprosessiin, osataanko niitä käyttää tehokkaasti ja toimiiko kommunikaatio? Osataanko suunnitella ja toteuttaa tehokas ja toimiva ratkaisu? Onko tiimillä riittävä kompetenssi työkaluista ja teknologioista, ratkaisumalleista ja menetelmistä? Onko tiimin arkkitehti ja tilaajan edustaja (Product Owner) riittävän asiantuntevia? Onko tiimin, koodareiden praktiikat oikeat ja riittävän luotettavat? Tuottaako tiimi laadukasta, toimivaa, skaalautuvaa, ongelman ratkaisemiseen sopivaa koodia vai tyytyykö se vain saamaan halutun toiminnon valmiiksi? Monta kysymystä siitä, mitä pitää ottaa huomioon.
Toteuttavaa tiimiä valittaessa on syytä keskittyä kokemukseen ja laaja-alaiseen teknologiseen osaamiseen sekä ymmärrykseen liiketoiminnasta. Jos palkataan vain koodareita tuottamaan toiminnallisuutta, saadaan usein vain niitä toimintoja. Tiimin valinta pelkkää buzzword bingoa pelaamalla tuottaa ehkä tiimin, joka tuntee valitut teknologiat, mutta ei kerro mitään tuotettavan koodin ja palvelun laadusta. Hyväksi koodariksi kasvaminen on pitkä tie ja siinä on harvoin oikopolkuja. Hyvät mentorit auttavat ihmiset pääsemään oikealle tielle ja pysymään sillä.
Koska alun perin kysyin mitä huono koodi maksaa, käytetään esimerkkiä ja tutkimuksia avuksi.
Tarinassa menetettiin hypoteettisesti n. 480 ostotapahtumaa viikon aikana keskimääräisen ostoksen ollessa noi 75 € arvoinen. Menetetty myynti oli vähintään 30 000 €. Korjaamiseen käytettiin viiden hengen kehittäjätiimin neljän viikon työaika, 75 000 € (100€/h). Jatkokehitys tehtiin vain 30% tuottavuudella, joten 75 000 € työpanoksesta turhaa oli jopa 70% eli päälle 50 000 €. Uusi ylläpitokumppani käytti ensimmäisen vuoden aikana keskimäärin yhden työpäivän viikossa ongelmien korjaamiseen ja ylimääräisiin huoltotöihin, kustannus 39 000 €. Projektin ongelmista johtuneet kustannusvaikutukset olivat yhteensä n. 200 000 € euroa. Kaupan vuoden myynnin arvo yli 5,5 miljoonaa euroa. Ilman tehtyjä korjauksia olisi menetetty myynti ollut jopa 35% eli 1,8 miljoonaa euroa vuoden aikana. Usein korjaukset tehdään myöhässä tai jopa jätetään kustannusten takia tekemättä, jolloin menetetty myynti realisoituu piilossa.
Kirjoitan seuraavalla kerralla enemmän käytännön ratkaisuista ja laadusta sekä miten siihen laatuun päästään.
Lähde: The Developer Coefficient: a \$300B opportunity for businesses
