Ohjelmistokehitysalaa riivaa sairaalloinen uutuudenviehätys. Pelko jälkeen jäämisestä ja häpeä vanhojen työvälineiden käytöstä ajaa ihmiset etsimään jatkuvasti uutta tekniikkaa. Vanhoja asioita ja jopa kokemusta halveksitaan. Se on selvää, että uusi teknologia on joskus hyvin tehokasta ja mahdollistaa ennennäkemättömiä asioita, mutta valitettavasti merkittävä osa uudesta teknologiasta ohjelmistokehityksessä ei ole tällaista. Seikkailujen tuloksina on usein heikkoja, välillä suorastaan vahingollisia, ratkaisuja.

Tekniset syyt eivät ole kovinkaan usein suorana syynä projektien epäonnistumisiin, mutta vaikuttavat usein aikatauluun ja budjettiin, ja voivat vaikuttaa viivästymisten ja hämmennysten kautta taustalla kriittisestikin. Tällä alalla teknologiaa kehittävät hyvin moninaiset tahot, joita voivat olla mm. yksittäiset ihmiset tekemässä omilla läppäreillään ohjelmia itseään varten, teknologiaa myyvät toimittajat tai suuryritykset rakentamassa järjestelmiä omille massiivisille tarpeilleen. Ongelmat ja ratkaisut ovat erilaisia eri organisaatioille. Teknologian rakentamisen motiivina voi olla esimerkiksi se, että monet kunnianhimoiset osaajat ja organisaatiot eivät tyydy siihen, että he ovat erinomaisia, vaan he haluavat tehdä mullistavia asioita ja saada miljoonat ihmiset käyttämään julkaisemiaan työkaluja. He uskovat, joskus aiheesta, joskus ei, rakentamansa työvälineen olevan parempi kuin mikään aiempi. Tekijä myös tuntee tekemänsä välineen läpikotaisin, joten hänelle se onkin tehokkaampi. Tarjontaa uudesta on hämmentävän suuri määrä ja suurin osa teknologioista kuoleekin pian pois.

Kaikki uusi ei siis ole parempaa kuin vanha tai edes aina hyödyllistä. Teknologiavaihdokset ovat tietysti tärkeitä ja tuovat hyötyjä järkevästi käytettyinä, mutta niitä tehdään niin paljon, niin vahingollisesti ja sellaisella uskonnollisella hurmoksella että on syytä pohtia myös teknologian vaihtamisen huonoja puolia.

Ongelmana eivät ole yksinkertaiset työkalut, jotka saa haltuun päivässä ja joissa muutenkin menetetyn sijoituksen riski on pieni, vaan perinpohjaiset asiat, joiden ymmärtäminen hyvin vaatii vuosia. Jos verrataan vaikkapa rakennusalaan, niin merkittävissä päätöksissä kyseessä on ennemminkin täysin uusi ja tuntematon rakennusmateriaali kuin yksinkertainen työkalu kuten uudenlainen vasara tai pora. Sen käyttäminen vaatii runsaasti henkilöstön aikaa, mikä on usein merkittävä menoerä ja joku joutuu aina maksamaan siitä. Asiakas konsulteille, organisaatio työntekijöille tai teknologiaosaaja itse vapaa-ajastaan opetellessaan.

Asiat, jotka tehtiin aiemmin hyvin tehokkaasti, tehdään monesti huonommin uuden teknologian kanssa. Uusi teknologia aiheuttaa ongelmia silloin, kun sitä ei osata käyttää riittävällä tasolla ja silloin kun sen kanssa ei voida käyttää muita työkaluja yhtä tehokkaasti kuin aiemman teknologian, ja ehkäpä tärkeimpänä, kun sen kanssa ei voida käyttää samoja käytäntöjä kuin aiemmin.

Erittäin merkittävänä ongelmana on ratkaisujen ylläpidettävyys, millä tarkoitan tässä laveasti yleistä muutettavuutta. Jos uusi työväline ei hypestä huolimatta lyönytkään läpi valtavirtaan niin tällä erikoisella tekniikalla rakennettua järjestelmää voi olla hyvin hankala muuttaa, koska sille ei löydy enää osaajia tai tukea muilta työvälineiltä. Ja vaikka teknologia olisi laajalti käytössä, niin siinä vaiheessa, kun se oli uutta kaikille, niin sillä tuskin osattiin tehdä asiat aina järkevästi. Useimmat legacy-järjestelmistä pitävät sisällään teknologisia ratkaisuja, jotka olivat joskus hyvinkin trendikkäitä, mutta jo parissa vuodessa alkoivat herättää kauhua. Käsitteet tahaton ja oleellinen monimutkaisuus ovat tuttuja jo vuosikymmenten takaa. Teknologinen monimutkaisuus, josta ei ole hyötyä, on juurikin aivan turhaa tahatonta monimutkaisuutta.

Uusi teknologia aiheuttaa siis lähes aina aluksi tehottomuutta, mikä on tiedetty jo vuosikymmeniä ohjelmistokehityksessä. Sokea luottaminen uuteen teknologiaan pelastajana on luokiteltu jopa klassiseksi virheeksi 1). Tästä huolimatta edelleen monet ovat sitä mieltä, että uusi teknologia vain nopeuttaa ja helpottaa kehitystä, aina ja poikkeuksetta. Se kuitenkin vaatii sen, että uusi teknologia on todellakin mullistavaa tai että aiempi teknologia ei sovi enää hyvin tarkoitukseensa. Eli uuden ja vanhan välillä on tällöin oltava merkittävä ero, mikä ei useimmin ole totta kun vaihdetaan ohjelmointikieltä tai ohjelmistokehystä trendikkäämpään. Todelliset mullistukset tapahtuvat harvoin.

Esimerkiksi webbiin tehtävät lomakkeet ovat pohjimmiltaan kohtalaisen yksinkertaisia ja perusta on muuttunut verrattain vähän kolmenkymmenen vuoden aikana, mutta erilaisten teknologisten ratkaisujen takia lomakkeet vievät hämmentävän paljon aikaa. Ja näitä eri tapoja rakentaa niitä on ollut vuosien varrella monia 2).

On hyvin erikoista, että älykkäiden ihmisten alalla tieteellinen perusta puuttuu lähes kaikesta. Teknologisten ratkaisujen arvioinneissa puhutaan hyvin harvoin tieteellisistä tutkimuksista. Uutta teknologiaa otetaan käyttöön mutujen, suosion, kuulopuheen ja blogiartikkeleiden perusteella. Teknologiakeskeiseen ajatteluun liittyy usein myös krooninen ratkaisupakkomielle, mikä estää äärimmäisen tärkeän ongelmanmäärittelyn tekemisen. Ratkaisuja tehdään vaikkei ymmärretä ongelmaa.

Pohdintaa syistä

Ongelma liittyy osaltaan siihen, että ohjelmoijia tulee alalle kiihtyvällä vauhdilla ja heitä ei kyetä opettamaan työn tekemiseen. Robert Martinin arvion mukaan joka viides vuosi ohjelmoijien määrä kaksinkertaistuu. Sanomattakin selvää, ettei sillä tahdilla kyetä sekä tekemään tulosta että samalla opettamaan uusia tekijöitä 3).

Ensimmäisten työvuosien aikana on myös todennäköisintä tehdä liian vaikeita ratkaisuja yleensäkin ja uuden teknologian huuma viekoittelee varsinkin näitä uusia kehittäjiä. Kokematon kehittäjä saa myös suhteellista etua siitä, että hän osaa uutta teknologiaa, sillä kokeneemmat ovat todennäköisesti joutuneet tekemään suurimman osan töistään vanhoilla teknologioilla. Kilpailussa kokemattomampi voi näin tasata välimatkaa. Ja toki kokeneemmillekin tulee painetta hankkia uutta osaamista, mikä saadaan parhaiten oikeasta täyspäiväisestä työstä, jolloin kehittäjän etu voi olla ristiriidassa organisaation edun kanssa.

Ongelmaa kiihdyttää se, että monet kokeneet ohjelmistokehittäjät siirtyvät muihin tehtäviin koska kyllästyvät opettelemaan miten sama asia tehdään taas kerran hieman eri tavalla tai eivät enää jaksa katsella miten projektit epäonnistuvat yksi toisensa jälkeen, johon yksi syy on liian monet uudet työvälineet, joiden yhteistoiminta ei ole selvää ja hypen loputtua ne eivät enää ole suosittuja, joten vain harva osaa sen jälkeen käyttää niitä. Ohjelmistot kuitenkin tuppaavat elämään vuosia, jopa kymmeniä vuosia, ja ylläpitoa tarvitaan usein koko sen ajan.

Kokenutta osaajaa voi alkaa myös masentamaan se tosiasia, että teknologista resettiä painetaan muutaman vuoden välein, jolloin kaikista tulee uudelleen harjoittelijoita. Onko se pikkumaisuutta, että vuosikymmeniä alalla ollut ei jaksa enää jatkuvasti tuntea, että hän ei osaa mitään, huolimatta siitä, että on opetellut uutta opettelemasta päästyään?

Moni on siirtynyt toisiin tehtäviin tällaisten muutosten tapahtuessa. Kannattiko pakottaa niin moni kokenut osaaja käyttämään uusia menetelmiä ja siten menettää heidät? Varmasti useilla on ollut paljon annettavaa seuraavissakin tehtävissään, mutta he eivät enää jaa parasta kokemustaan teknologiaratkaisujen kanssa.

Monelta tuoreelta ohjelmoijalta kysyttäessä millään muulla kuin teknologialla ei ole väliä. Kokeneemmat ovat useimmiten sitä mieltä, että teknisessä kehityksessä on tärkeää mm. ohjelmiston muuttamisen nopeuden pitäminen riittävänä, mittaaminen, dokumentointi, työnkulut ja viestintä yleensäkin. Ja nämä ovat vain lähellä teknologiaa olevia asioita. Katsottaessa ylemmältä tasolta vaikkapa vaatimusmäärittely, laadunvalvonta, tietoturva, tietosuoja, hankesuunnittelu ja projektinhallinta merkitsevät usein huomattavasti enemmän kuin tekniset asiat.

Mitään näistä ei kuitenkaan voi tehdä järkevästi, jos tiimi taistelee sen kanssa, että ylipäänsä ymmärtää miten pohjalla olevaa teknologiaa käytetään. Varsinkin tietoturvan kannalta uusi teknologia on suuri riski, koska sitä ei ole käytetty vielä niin paljoa, joten aukkoja on enemmän löytymättä ja tietoturvallisten ratkaisujen tekemistä ei vielä välttämättä osata.

Tilannetta pahentaa vaikeus ymmärtää uuden teknologian tuomia hyötyjä ja haittoja. Useimmiten uutta teknologiaa otetaan käyttöön vain siksi, että ”kaikki” muutkin käyttävät sitä. Välillä tämä vaikuttaa pyramidihuijaukselta. Teknologian elinkaaren alussa kovat osaajat saattavat opetella sitä ja pitää paljon meteliä tästä uudesta osaamisestaan, jolloin muut alkavat myöskin kiinnostumaan tästä uudesta teknologiasta seuratessaan heitä. Monesti on kyllä järkevää seurata mitä muut tekevät, sehän tulee jo laumaeläinvaistoista ja voi kannattaa etenkin, jos oma ydinliiketoiminta ei pyöri aivan teknologian ympärillä. Mutta kaikilla on omat motiivinsa, joten muitten peesaaminen voi lyödä sormille. Uuden teknologiaosaamisen myyminen on kannattavaa pioneereille, sillä yleisen erottumisen lisäksi koulutusliiketoiminta ja maine ovat erittäin hyödyllisiä asioita. Ne, jotka ottavat teknologiaa käyttöön ensin, kärsivät mahdollisesti alussa, mutta sen jälkeen kun siitä on tullut valtavirtaa he pystyvät myymään kalliilla oppejaan. Ja todennäköisesti hypen takia alussakin joku muu on valmis maksamaan, varsinkin jos ei osaa vaatia, että käytetään vain tuttuja teknologioita. Eli itsekkäästi ja ahneesti ajateltuna kannattaa siis olla ensimmäisten joukossa, vaikka työkalun nettohyöty olisi nolla. Uudenlaiset ärsykkeet myös altistavat manipuloinnille, joten senkin ansiosta uutta teknologiaa saa helposti myydyksi.

Läheskään kaikki eivät kuitenkaan myy tarpeettomia uusia tekniikoita pahuuttaan. Esimerkiksi monet haluavat uskoa uuteen ratkaisuun ja katsovat siitä vain hyviä puolia, toivoen että vihdoin vanhat ongelmat häviävät. Valitettavasti usein syntyy uusia ongelmia vanhojen tilalle. Toisaalta ihminen myös ottaa jo luonnostaan mallia muiden käytöksestä, joten osa lähtee siksi mukaan meininkiin. Varsinkin jos nämä muut vaikuttavat olevan auktoriteetteja, mitä usein myös teknisesti taitavat ihmiset ovat omalla erikoisalueellaan. Osaltaan niukkuus ja vaikeus kiinnostavat ja houkuttavat ihmisiä, ja alussahan uusi osaaminen on harvinaista 4). Hankalien haasteiden viehätys saa aikaan vielä pahemman ilmiön, jos otetaan mukaan sellainen uusi työväline, mikä on vaikeakäyttöisempi kuin vanha.

Miksi esimerkiksi pilvipalvelu Heroku ei saanut aikaan samanlaista hypeä kuin monet muut palvelut, jotka vaativat paljon enemmän työtä ja ylläpitoa? Oma näkemykseni on, että ihmiset haluavat tehdä monimutkaisia asioita. Yksinkertainen olisi liian helppoa.

Tuskaa helpottaa kuitenkin hieman se, että samoja asioita kierrätetään. Vanha sanonta kuuluu, että jokainen sukupolvi keksii Lispin uudelleen. Tämä on tilanne monien asioiden suhteen, sillä usein ”uusi” teknologia on vanha idea uudella nimellä.

Ohjelmistokehityksessä uusi teknologia lisätään yleensä aiemman ja monimutkaisen järjestelmän uudeksi osaksi, mikä on harvoin yksinkertainen toimenpide. Kuva: Hoover Tung, Unsplash

Mitä voimme tehdä?

Joku voisi karjaista tässä vaiheessa, että tämä on pelkkää osaamisen puutetta ja koulutus korjaa asian! Valitettavasti tämä on teknologiaosaamisen kanssa useimmiten juuri päinvastoin, sillä vaivalla hankittuja taitoja halutaan käyttää mahdollisimman paljon eikä yleensä ehditä miettimään, että onko siitä hyötyä organisaatiolle. CV saa merkintöjä trendikkäistä työvälineistä ja vertaiset arvostavat uutta osaamista, mikä on varsinkin elinkaaren alkuvaiheessa harvinaista. Teknologioiden vaikutus organisaatioihin ja liiketoimintaan on yleensäkin vaikea mitata, joten sitä ei monesti tehdä. Tietysti teknologiaosaaminen on perusedellytys, mutta koulutuksessa ja osaamisessa on kehittämistä enemmänkin mittaamisessa ja teknologioiden arviointikyvyissä.

Uuden teknologian käyttöönotto on siis täynnä vaaroja, mutta vanhallakaan ei välttämättä pärjää loputtomiin. Siirryttäessä uuteen on hyvä käyttää seuraavia keinoja:

  • Vanha viisaus: vain yksi uusi asia kerrallaan per projekti
  • Oman asemoinnin tarkka harkitseminen suhteessa teknologia-aaltoon eli kannattaako olla tekniikan eturintamassa hakemassa jotain muuta etua tehokkuuden kustannuksella 5)?
  • Pilotointi jossa on mukana haastavia osuuksia ja sen onnistuminen mitataan suhteessa vanhaan tapaan tehdä
  • Mittaaminen. Se on vaikeaa ja epätarkkaa, mutta usein jo välttävä mittaus antaa elintärkeää tietoa siinä missä olematon mittaus ei anna mitään
  • Liiketoiminnan, tuottavuuden ja ohjelmistojen muutettavuuden priorisointi ja tarkkailu
  • Vaikeissa paikoissa yksinkertaisuus on erittäin hyvä nyrkkisääntö. Jos ei tiedä mitä tehdä, on parempi valita yksinkertaisempi vaihtoehto. Steve McConnellin mukaan tärkein tehtävämme on hallita monimutkaisuutta 6).
  • Organisaation sisällä uuteen teknologiaan tutustuminen ja henkilöstön tietyn osan erikoistuminen hyvissä ajoin
  • Teknologiamuutosten arviointi ja seuraaminen sekä siitä saatavan tiedon käyttäminen seuraavissa teknologiavalinnoissa
  • Riittävät resurssit, esim. infra, koulutukset, kirjallisuus, työasemat ja aika
  • Avoin ilmapiiri, mikä sallii keskustelun, kritiikin ja kokemusten jakamisen
  • Asiantuntija-apu
  • Verkostoituminen muiden samaa tekniikkaa käyttävien kanssa
  • Tiedostaminen että suosio ei ole tae toimivuudesta. Hyvin suuria pettymyksiä tuottaneet teknologiat ovat olleet erittäin suosittuja
  • Syvään hengittäminen ja asioiden suhteuttaminen. Webbilomake ja sähköpostin lähetys eivät yleensä muutu kovinkaan montaa kertaluokkaa paremmiksi uusilla leluilla
  • Hyväksy pieni epätäydellisyys. Ehdoton, jääräpäinen täydellisyyteen pyrkiminen voi aiheuttaa järkyttäviä kuluja
  • Voi olla merkki ongelmasta jos jostain teknologiasta puhutaan jatkuvasti. Varsinkin jos vähemmän teknisissä tehtävissä olevat puhuvat siitä
  • Selvitä miten uudesta teknologiasta pääsee eroon. Jossain vaiheessa se on legacya ja uudempaan halutaan jälleen vaihtaa

Ohjelmistokehitysala on heikosti toimiva ja on todennäköisesti aina ollut. Se on nyt myös tärkeämpi kuin koskaan. Onko meillä varaa toimia heikosti ja menettää jatkuvasti kokeneita ammattilaisia?

Lähteet

  1. Steve McConnell. Rapid Development, 1996, kpl 3. Classic Mistakes, #33: Silver-bullet syndrome, #34: Overestimated savings from new tools or methods, #35: Switching tools in the middle of a project
  2. ”Building forms for the web remains one of the perennial challenges of front-end development, in particular with React.” ThoughtWorks Technology Radar 1/2021. https://www.thoughtworks.com/radar/archive
  3. Robert Martin. My Lawn, https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
  4. Robert B. Cialdini. Influence, 2007, kappaleet Social proof s114-164 ja Authority sekä Scarcity 208-271
  5. Steve McConnell. Code Complete, 2004, s66 Your Location on the Technology Wave
  6. Steve McConnell. Code Complete, 2004, s78 Importance of Managing Complexity

Heikki Naski on ollut ohjelmistokehitysalalla moninaisissa tehtävissä 2000-luvun alkupuolelta asti, seurannut alaa maailmanlaajuisesti ja ollut avoimen lähdekoodin projekteissa sekä järjestötoiminnassa. Hän on perehtynyt ammattilaisten näkemyksiin myös aiemmilta vuosikymmeniltä haastatteluiden ja kirjallisuuden kautta.