null Ohjelmistoversion kuolema

Ohjelmistoversion kuolema

Ensimmäisessä alan kesätyöpaikassani päädyin kirjoittamaan koodin viikkonumeron laskemiseksi päivämäärästä. Tuohon aikaan tuon suuren yrityksen järjestelmissä päiväysten vuosikentässä oli vielä vain kaksi numeroa, mutta vuosi 2000 oli jo tiedostettu ja vaatimuksena oli koodini toimiminen myös vuoden 00 jälkeen. Totesin kuitenkin heti mahdottomaksi, että koodini tulisi toimimaan yli sataa vuotta, kun syötteenä on vain kaksinumeroinen vuosi. Tämä pala koodistani päätettiin myös sisällyttää yrityksen koodikirjastoon ja jouduinkin dokumentoimaan melkoisesti, että tämä lakkaa toimimasta vuonna 2080.

Muisto palasi eilen mieleen, kun kuulin tietoturvawebinaarissa Suomen valtiolla edelleen olevan (tai ainakin olleen hiljattain) ajossa ohjelmia vieläkin varhaisemmalta ajalta; ennen internettiä mutta kuitenkin jo lähiverkossa toiminutta. Tietoturvauutisista päätellen myös Windows 10:ssä on edelleen NT:n koodia tai ainakin sen bugit ajossa. Toisaalta olen jo ehtinyt osallistua 10 vuotta vanhan koodini korvaavan koodin kirjoitukseen, mikä sekin on jo korvattu. Vanhat käyttäjämme muistanevat hotpage- ja sui-palvelut, jotka edelsivät nykyistä my.csc.fi:tä.

Vaikka itse koodin ikä voi olla pitkäkin, sen tietyn version elinkaari harvoin ylittää 10 vuotta ja normaali LTS (Long Term Support) versio saa tyypillisesti ainakin ilmaista tukea vain 4-5 vuotta. Itseasiassa monien ilmaisohjelmistojen bisnesidea onkin tuen myynti vanhoille versioille.

Sovelluskehittäjänä käytän paljon muiden luomia pieniä kirjasto-ohjelmia. Niille yleensä ei ole määritelty EOLaa (End Of Life) kuten tärkeämmille ohjelmistoille, kuten esimerkiksi käyttöjärjestelmän ja ohjelmointikielen tietylle versiolle. Joudun siis tutkimaan versionumeroa. Milloin ja miten säännöllisesti kirjastoa on viimeksi päivitetty, onko riippuvuuksia tai yhteystietoja ym. metatietoja. Osakemarkkinoiden tapaan tämä historiatieto ei ole tae tulevasta. Vaikka historia näyttäisi hyvältä, ovat päivitykset tosiasiassa voineet loppua jo ennen kuin otan kirjaston käyttöön omassa uudessa ohjelmassani.

Enemmistö käyttämistäsi ohjelmistoista sisältää zombie-komponetteja, jotka eivät tosiasiassa ole elossa, mutta joiden kuolema ei ole ilmeinen. Lähes aina yrittäessäni ottaa yhteyttä henkilöön viittaavalla sähköpostiosoitteella ohjelmiston kehittäjään, paluuviesti on Mailer-Daemonilta: "tuntematon vastaanottaja". Kuoleman epäselvyyttä korostaa, että ongelmia syntyy yleensä vasta ympäristön muuttuessa. Tämä pitkähkö zombie-kausi aiheuttaa myös sen, että lähdekoodin avoimuus ei pelasta ongelmaa näissä tilanteissa, sillä korjattavaa ei ole vain pienen ympäristömuutoksen verran vaan laajemminkin.

Ohjelmiston iän kasvaessa sen laadukkaimmatkin komponentit kuolevat. Minulla on 30 vuotta vanha polkupyörä. Siinä ei ole yhtään alkuperäistä osaa. Myös runko hajosi pian 10 vuoden takuuajan jälkeen ja koska olin huollattanut pyörän viimeisen päälle kalliisti ennen rungon hajoamista, panin rungon vaihtoon, vaikkei se oikein kannattanutkaan. Olen toistanut muuten virheen pienemmässä mitassa myöhemmin. Samoin ohjelmiston iän kasvaessa reagointi komponenttien kuolemaan on helposti epälooginen.

Laadukkaasta tuotteesta on tullut uusi versio hyvissä ajoin ennen vanhan version hyvin ennakoitua kuolemaa. Miksi päivitys jää tekemättä tai viime tippaan? Sisältääkö organisaation ylläpidon määritelmä myös ohjelmiston komponenttien päivityksen. Seurataanko organisaatiossa koko asiaa?

Toinen ongelma on ajoitus. Päivitystä .0 versioon kartetaan, usein aiheesta. Ainakin netistä on helpompi löytää ohjeita, jos ei ole itse ensimmäisenä päivittämässä. Mutta myöhemminkin voi olla vaikeaa: päivityspolku on selvä vain tiettyjen versioiden välillä. Koska ohjelmisto koostuu tyypillisesti monesta riippumattomasta komponentista, on helppo ajautua tilanteeseen, jossa uuden toimivan versiokokoelman löytäminen on vaikeaa tai vaatii oman ohjelmiston muuttamista. Lisäksi ohjelmistojen julkaisut eivät ole kaikkein täsmällisimpiä tapahtumia.

Lisää tästä aiheesta » Siirry sisältöihin ja uutisiin »

Pekka Järveläinen

Pekka Järveläinen on työskennellyt CSC:llä pitkään ohjelmistokehitysprojektien parissa.

pekka.jarvelanen@csc.fi