Meillä Monadilla uskotaan kestävään ohjelmistokehitykseen; kaikessa toiminnassa pyritään luomaan mahdollisimman laadukas ohjelmistotuote oikeaan tarkoitukseen pienimmillä kokonaiskustannuksilla. Jotta tähän päästäisiin, keskeisenä tavoitteena on kehittää alusta asti tuote, jolla on pitkä elinkaari.

Monet tosimaailman esimerkit antavat kuitenkin syyn epäillä, ovatko kohtuulliset kustannukset ja pitkä elinkaari edes mahdollinen yhdistelmä. Projektin alussa muutokset ohjelmistoon saadaan nopeasti, mutta myöhemmässä vaiheessa ne vaikuttavat tuskaisen hitailta, mikä antaa mielikuvan aina vain nousevista kustannuksista. Pitkän elinkaaren tuotteen arvoa nakertavat osaltaan esimerkit, joissa tuote ei millään pysty reagoimaan muuttuviin vaatimuksiin. Usein molempien ongelmien uskotaan korjaantuvan sillä, että tuodaan uusi tuote korvaamaan vanha.

Nousee kysymys: jos ohjelmistotuotteet täytyy kuitenkin tehdä uudelleen, onko ollenkaan edes kannattavaa pyrkiä tekemään ohjelmistoa, jonka tarkoituksena on olla pitkän elinkaaren tuote? Me sanomme, että kyllä on. Sen lisäksi väitämme, että vaikka tarkoituksena on tehdä korkealaatuinen ja pitkään kestävä ohjelmistoratkaisu, on se myös lopulta halvempi vaihtoehto.

Tähtäimessä tuotteelle pitkä elinkaari

Useimmilla uusilla ohjelmistoilla on tavoitteena olla pitkään käytettävä tuote, vaikka sitä ei projektin alkuvaiheessa erityisesti ajateltaisi niin. Joitain poikkeuksia tietysti on: voidaan haluta tehdä esimerkiksi kertaluontoinen projekti, jossa kokeillaan jonkin asian toimivuutta tai tuote voi olla luonteeltaan sellainen, jota käytetään vain hetken aikaa. Kuitenkin usein kun harkitaan uuden ohjelmistotuotteen tilaamista, on tahtotilana saada tuotos, joka tuottaa arvoa pitkälle tulevaisuuteen. Ostaja haluaa saada käyttöön hyvän ohjelmistotuotteen, joka palvelee ensimmäisestä versiosta lähtien ja jota pystytään parantamaan ilman, että tarvitsee tehdä suuria ja kalliita muutosprojekteja; puhumattakaan, että joudutaan rakentamaan uusi korvaava ohjelmisto.

Ohjelmiston kehittäminen on lähes aina mittava projekti. Siitä syystä monet ohjelmistotuotteet – riippumatta siitä onko ne tehty hyvin tai huonosti – ovatkin käytössä pitkään. Pitkään käytössä olevista järjestelmistä ensimmäisenä tulee mieleen jättimäiset lentokentän tai terveydenhuollon järjestelmät, joihin investoidaan aluksi paljon ja niitä käytetään tunnollisesti kymmeniä vuosia osittain näiden korkeiden investointien vuoksi. Kuitenkin myös pienellä kustannuksella tehty ja hyvin rajattu tuote voi olla pitkään käytössä. Hyvänä esimerkkinä on Windows Task Manager, joka on yksinkertainen sivuprojektina aloitettu ohjelmisto, mutta on pohjimmiltaan sama 25 vuoden jälkeen [1]. Silti se on joka päivityksen jälkeen näyttänyt vähän erilaiselta ja sen käytettävyys on parantunut.

Siinä on kuitenkin selvä ero, onko tuote kehitetty kestävän ohjelmistokehityksen periaatteiden mukaisesti vai ei. Mitä eroa on ohjelmistotuotteella, jota käytetään pitkään ja pitkän elinkaaren käyttöön suunnitellulla kestävästi kehitetyllä ohjelmistotuotteella? Jos tuotetta ei kehitetä kestävän ohjelmistokehityksen mukaisesti, se saattaa kyllä olla pitkään käytössä, mutta sen kustannukset kasvavat ja kun uusia ominaisuuksia ei enää saada helposti lisättyä, sen käyttäjät alkavat toivomaan parempia vaihtoehtoja. Tällöin tuotteen potentiaalinen arvo jää saavuttamatta ja pahimmillaan tuotteesta tulee enemmän ongelmia kuin hyötyjä. Jos tuotetta yritetään tehdä ainoastaan lyhyellä tähtäimellä, voi näyttää siltä, että saadaan lyhyen aikavälin “voittoja”, mutta niistä voitoista joudutaan maksamaan moninkertaisesti myöhemmin. Tässä taustalla on jo pitkään tunnettu fakta: jokaiseen tuotteeseen tarvitaan aina muutoksia.

Menestyvä ohjelmistotuote on aina keskeneräinen

Kuvitellaan uuden ohjelmistotuotteen syntyhetkeä: ohjelmistotuotteen hankkijalla on usein paljon ajatuksia, mitä valmiilla tuotteella pitäisi saada tehtyä, mutta ne ovat harvoin suorilta käännettävissä toimivaksi ohjelmistotuotteeksi. On usein huomattu, että ajatukset selkenevät parhaiten siinä vaiheessa kun itse kehitystä tehdään; löydetään parempia tapoja täyttää käyttäjän tarpeet ja huomataan, että joitain asioita ei kannata tehdä ollenkaan. Tässä prosessissa kokenut projektitiimi on erityisen arvokas: asiantuntevat tekijät tietävät projektin alkuvaiheessa mihin kannattaa panostaa, jotta voidaan tehdä oikeita asioita ja jättää epäoleellisemmat asiat myöhemmäksi. Projektin edetessä yksityiskohdat jatkavat hahmottumistaan ja kun pohjatyö on tehty se mielessä että muutoksia tullaan tekemään, ne pystytään tekemään helposti.

”Successful software always gets changed” – Fred Brooks

Voidaan helposti olettaa, että kukaan ei halua tehdä ohjelmistoa, joka ei ole onnistunut tai menestyvä. Oli kyse ohjelmistosta, joka tehostaa liiketoiminnan osa-alueita sisäisesti tai on itse uusi myytävä tuote, sen halutaan olevan menestys. Menestys tuo tullessaan isompia käyttäjämääriä ja uusia käyttötarkoituksia – ja näiden kautta lopulta myös muutoksia ohjelmistoon. Toisaalta vaikka ihanteellisesti kaikki muutokset johtuisivat mahtavasta menestyksestä, joudutaan ohjelmistoon tekemään myös muutoksia vähemmän miellyttävistä syistä. Jokaisesta ohjelmistosta löytyy kovalla käytöllä puutteita, joita ei ole aluksi otettu huomioon, tai jotkut toiminnallisuudet eivät jossain käytännön tilanteissa vain toimi.

Oli syy menestys tai puutteelliset ominaisuudet, yksi keskeinen asia on kuitenkin selvä – käytössä olevaan ohjelmistotuotteeseen tulee aina muutospaineita. Tämän vuoksi on epärealistista ajatella, että ohjelmistotuote olisi valmis kun ensimmäinen versio siitä syntyy. Jos haluaa oikeasti selvittää mitä ohjelmistotuotteen tekeminen maksaa, täytyy katsoa pidemmälle.

Kestävä kehitys on halvempaa vaikka se ei aluksi näytä siltä

On tärkeää tuoda esiin, että kestävä ohjelmistokehitys, jonka lopputuloksena pyritään tuottamaan pitkän elinkaaren tuote, ei tarkoita sitä, että tuotteen ominaisuuksia tehtäisiin pitkään. Sen sijaan kehityksessä otetaan huomioon, että tuotettava ohjelmisto on pitkäikäinen ja pitkän iän aikana sen tarvitsee olla myös joustava siihen kohdistuville muutospaineille. Tämä on myös halvempaa, koska kuten itse ohjelmistoa, myös kustannuksia pitää katsoa pitkällä tähtäimellä.

Kustannuksia ei kuitenkaan aina haluta tai voida katsoa pitkällä tähtäimellä. Ohjelmistoprojektien kilpailutustilanteet ovat erityisen alttiita sille, että keskitytään lyhyen aikavälin kustannuksiin. Kovan kilpailun vuoksi ohjelmistotaloilla on usein paine tarjota ohjelmistoa, joka näyttää tarjousten vertailussa hyvältä kilpailijoihin nähden. Tarjouksessa pyritään tuomaan kehittämisen kustannukset mahdollisimman alas ja saada lopputulos näyttämään nopeasti toteutettavalta. Paperilla hyvältä näyttävä tarjous luultavasti saa paremman sijoituksen kilpailijoihin nähden ja saa täten paremmat todennäköisyydet tulla valituksi. Todellisuudessa liian hyvältä näyttävä tarjous sisältää kuitenkin ainoastaan ensimmäisen version kustannukset.

Jos keskitytään vain ensimmäisen version kustannuksiin, tehdään nopeasti virhearviointeja. On tutkittu, että suurin osa koko elinkaaren kustannuksista syntyy vasta ensimmäisen version julkaisun jälkeen – jopa 60-80 % [2]. Usein “nopeasti tehdyllä” ja vain paperilla hyvältä näyttävillä tuotoksilla on lisähinta, mikä näkyy kalliina eränä ensimmäisen version jälkeisissä kustannuksissa, ja jonka kanssa joutuu elämään mahdollisesti koko tuotteen elinkaaren ajan: alhainen sisäinen laatu (kts. artikkeli). Alan ammattilaiset ovat huomanneet, että vaikka nopeasti tehty ensimmäinen versio voi näyttää aluksi halvemmalta, ohjelmiston jatkokehityksessä huomataan alhaisen laadun aiheuttavan hidastuksia ja lisäkustannuksia [3]. Ja kuten ollaan huomattu, jos ohjelmistoa aiotaan käyttää, jatkokehitystä on aina tulossa.

Lähdetään kestävällä kehityksellä alusta lähtien

Ohjelmistoa kannattaa aina lähteä tekemään kestävän ohjelmistokehityksen mukaisesti heti alusta lähtien. Kun ohjelmistolla on käyttöä, sille tarvitaan ominaisuuksia, että se voi muovautua tulevaisuuden paineiden edessä. Samalla tuotetta, jota ei käytetä ei kannata lähteä edes tekemään. Jotta jatkokehitys olisi nopeaa ja kustannustehokasta, pitää tulevat muutokset huomioida aina uusia ominaisuuksia suunniteltaessa ja kehitettäessä. Jos alkaa etsimään pikavoittoja aikaisissa vaiheissa, päädytään pian tilanteeseen, missä muutokset ovat koko ajan hitaampia ja täten myös kalliimpia. Tämä on tilanne, joka ei palvele ketään.

Monad haluaa olla tekemässä laadukkaita ohjelmistotuotteita, joita ei haluta korvata hetkeen. Tämän vuoksi jo projektin alkuvaiheessa ollaan tarkkoja että tehdään päätöksiä, jotka mahdollistavat ohjelmiston joustavuuden kun vaatimukset vääjäämättä kehittyvät. Kun nämä asiat ovat mielessä alusta lähtien, saadaan lopputulos joka on laadultaan korkea ja kustannustehokas. Samalla saadaan lopputuloksena sellainen ratkaisu, joka saavuttaa parhaimman lopputuloksen ohjelmiston loppukäyttäjille, sen kehittäjille ja sen tilaajalle.

Lassi Pohjoisvirta

Senior Software Engineer

Lähteitä:

[1] 01. Secret History of Windows Task Manager – Part 1 – Origins (viitattu 26.2.2021) https://www.youtube.com/watch?v=f8VBOiPV-_M

[2] Continuous Quality Control of Long-Lived Software Systems (viitattu 27.1.2021): https://www.cqse.eu/fileadmin/content/news/publications/2009-continuous-quality-control-of-long-lived-software-systems.pdf

[3] Is Quality Worth the Cost? Martin Fowler (viitattu 27.1.2021) https://martinfowler.com/articles/is-quality-worth-cost.html