Molemmissa ratkaisuissa on riskinsä: Mikäli valitaan tuoretta teknologiaa, jää käsiin vähemmän teknologista velkaa, mutta syliin voi tuppautua ongelmia keskeneräisen dokumentaation tai puutteellisten ominaisuuksien muodossa. Uusi teknologia voi jäädä tähdenlennoksi, mutta se saattaa myös löytää paikkansa vakavasti otettavan softan riveistä.

Vanhalle ja vankalle teknologialle kannattaa antaa arvoa. Varttuneelle teknologialle on kehityskaarensa mukana tullut lukuisia parannuksia, esimerkiksi tietoturvan osalta. Ikä on softalle kaksiteräinen miekka: toisaalta vuosirenkaat tuovat liudan ongelmia, mutta toisaalta varttuneisuus voi tuoda niin tukea, dokumentaatiota, kuin vaikkapa toimivia työkaluja.

Nuori softa ei tähän välttämättä vielä taivu, mutta ehkäpä vanhan softan fundamentaalisia ongelmia on ratkaistu. Näin on jo tehty ohjelmointikielissä, esimerkiksi Kotlin, Go ja Rust.

Onko uudempi aina parempi?

Uuden teknologian kanssa työskenteleminen on monelle kehittäjälle mieluisa haaste. Yleensä asiakaskin on tyytyväinen, kun koodikanta on ymmärrettävä, siisti ja toteutettu viimeisimmillä teknologioilla. Miksi sitten uutta tehdessä ei välttämättä ole järkevää kahmia kasapäin uutuuksia hyllystä?

Teknisellä alalla on aina tärkeää olla visionääri. Visionääri ei kuitenkaan saa olla ahmatti; ainesosat hyvälle ohjelmistolle pitää valita tarkoin, ja mittapuuna on oltava niin teknologian vakaus, tuki ja relevanssi, kuin sen
tulevaisuusarvokin. Uutuus sinänsä ei ole itseisarvo.

Moni ohjelmisto on kuin päivänkorento: se elää vain lyhyen ajan. Tästä hyvänä esimerkkinä on Node-ympäristön mittava pakkausvalikoima: moni hyvä pakkaus kokee ennenaikaisen lopun, kun kehittäjä hylkää sen. Avoimen lähdekoodin projekteille ei monesti löydy ylläpitoa – etenkään silloin kun kirjastolla ei ole suurten yritysten tukea.

Elintärkeät päivänkorennot

Tuotteiden laajassa ekosysteemissä on toki oma lokeronsa niin lyhyen pyrähdyksen kuin pitkän elinkaarenkin ohjelmistoille. Ylläpidon puutteen vuoksi häviävät ohjelmistot ovat pieniä tragedioita, mutta lyhyt elinkaari ei
aina tarkoita tuotteen epäonnistumista.

Järjestelmän tietoturvaa kehittäessä voidaan turvautua “penetraatiotestaukseen”, eli tekniikkaan, jossa järjestelmään tehdään simuloituja hyökkäyksiä vaaraa aiheuttamatta. Tietoturvariskejä kartoitetaan kokeilemalla mahdollisia tietoturva-aukkoja. Testauksessa käytettävien skriptien ja pienten ohjelmistojen elinkaari päättyy, kun mahdollinen tietoturva-aukko korjataan.

Ohjelmisto on paljon muutakin valmis tuote, jota loppukäyttäjä käyttää. Tuotteen kehityksessä usein luodaan prototyyppejä ja “proof-of-concept” – demoja tuotteesta tai ominaisuudesta, joka mahdollisesti toteutetaan. Prototyyppejä käytetään jatkuvasti esimerkiksi UI/UX -suunnittelussa, jossa on elintärkeää, että valmiista käyttöliittymästä on hahmotelma, jota voidaan hyödyntää niin projektin organisoinnissa kuin sen toteutuksessakin. Prototyypin luonti voi olla projektin koosta ja luonteesta riippuen kuukausien tai jopa vuosien projekti.

Älä poimi homeista koodia!

Leipävalikoimasta pitäisi kotiin viedä tuorein leipä – mikä avuksi, jos saman haluaa tehdä ohjelmistojen kanssa? Ohjelmistokehityksessä tulee välttämättä vastaan tilanteita, joissa lukemattomista vaihtoehdoista pitää
valita projektiin sopivin. Mistä silloin tietää, mikä palanen valitaan ja mikä jätetään laariin?

Vaihtoehtoja valitessa on paljon mittareita, ja on subjektiivista, mitä niistä kannattaa tiirailla: Kuka teknologiaa käyttää? Löytyykö teknologialle osaamista? Mikä on teknologian tulevaisuus?

Relevantin teknologian valitseminen ei ole helppoa, mutta suurimmat miinat ovat helposti vältettävissä. Mikäli ohjelmiston suunnitteluun ja teknologioiden huolelliseen valintaan käytetään oikea määrä resursseja, on pitkällä tähtäimellä lunastettavissa suuria palkintoja niin ohjelmiston skaalautuvuudessa kuin sen ylläpidossakin.

Usein valinta teknologialle tehdään sen perusteella, mitä osaamista tiimistä löytyy jo valmiiksi. Tämä on monesti hyvä tapa toimia, mutta aina teknologiaa valitessa pitää pysähtyä miettimään, olisiko nyt oikea hetki astua askel eteenpäin ja samalla uudistaa myös tiimin osaamista. Tämä onkin tärkein ohje oikean teknologian löytämiseen: pysähdy miettimään.

Uuden teknologian käyttöönotossa on hyvä kuunnella niin ohjelmiston käyttäjää, tilaajaa, kuin kehittäjiäkin. Nämä aksioomat ovat tosia niin kauan, kun ohjelmisto elää ja hengittää vapaassa tilassa, eikä ole tarkkoja rajoitteita sen suhteen, mistä rakennesosista se koostuu. Nimittäin suurin osa olemassa olevasta ohjelmistosta on tätä “rajoittunutta” softaa ja siihen puolestaan pätevät aivan omat lainalaisuutensa. Tällä kertaa pohdimme sitä harvinaista tilannetta, jossa meillä on valinnanvaraa sen suhteen, mistä rakenneosista softamme rakentuu.

Me Weasel Softwarella olemme kokeneita kehittämään myös sellaista ohjelmistoa, jossa toimitaan tietyissä, tarkoissa rajoissa. Näissä tilanteissa on omat pulmansa, ja niitä pääsemme pohtimaan seuraavalla kerralla!