Ohjelmointi - suurenmoista ja raivostuttavaa

Kone vapautti ihmiskunnan työn orjuudesta - tai muutti orjuuden uudenlaiseksi. Joka tapauksessa, kone on teollisen vallankumouksen ikoni ja samalla sen keskeinen vaikuttaja. Mutta kuka keksi koneen? Emme tiedä, sillä ihmiskunta on rakentanut koneita jo ainakin pari tuhatta vuotta.

Ehkä olennaista onkin käyttövoima. Ihmiskunta on vaeltanut käyttövoiman vallankumouksesta toiseen. Eläinten voima - vesi- ja tuulivoima - höyryvoima - polttomoottori - sähkövoima. 

Koneet ovat suurenmoisia. Mutta kun tarpeemme muuttuvat, joudumme rakentamaan uudenlaisia koneita. Siihen tarvitaan paljon työtä. Mutta insinöörit ovat keksineet ratkaisuja, kuten modulaarisuuden. Koneet voidaan rakentaa samankaltaisista osista, ne vain kootaan uudella tavalla. Ja nuo osat voivat olla vakioituja, niin että niitä voidaan tuottaa edullisesti ja käyttää yhä uusiin sovelluksiin. Pyörät, laakerit, akselit, ruuvit, rattaat, ketjut, letkut, putket pumput, ja lukemattomat sähkökojeet taipuvat uusien koneiden rakenneosiksi, usein vain vähäisin muutoksin. 

 

Sitten keksittiin tietokoneet. Robotiikassa ja konetekniikassa tietokoneiden käyttöönotto merkitsi isoa muutosta. Uuteen sovellukseen ei tarvitsekaan välttämättä rakentaa uudenlaista konetta, vaan riittää, että muutetaan sen ohjelmaa. Lisäksi syntyi kokonaan uusi ala: informaatiotekniikan monet sovellukset yhteiskunnassa ja organisaatioissa. Kaikesta tästä seurasi, että ohjelmoinnista tuli nopeasti kasvava teknisen taidon alue. Uusien ohjelmien tarve kasvoi nopeasti. 

 

Ohjelmoinnin tehostamiseksi syntyi ohjelmiin perustuvia ratkaisuja. Se oli itseään vahvistava kierre. Keksittiin symboliset konekielet eli assemblerit, ja sitten niin sanotut korkean tason ohjelmointikielet, jotka olivat keinotekoisia ongelmanläheisiä kuvauskieliä. Kuuluisia varhaisia kieliä olivat Fortran, Algol, Cobol ja Basic*. Ohjelmien tarve kasvoi nopeasti, ja ohjelmat tulivat yhä laajemmiksi ja monimutkaisemmiksi. Niiden tekemiseen tarvittiin alati ja nopeasti lisääntyvä määrä ihmistyötä, ja lisäksi laajoissa ohjelmissa piileskeli paljon vaikeasti löytyviä virheitä, ammattikielellä "bugeja", ötököitä. Alettiin puhua ohjelmistokriisistä.

Ohjelmointikieliä on kehitetty ällistyttävä määrä. On kehitetty tehokkaampia tapoja ohjelmoida, ja myös ohjelmoinnin sovellusalueet laajenevat jatkuvasti. Itse opettelin ensimmäisenä ohjelmointikielenä Algolin vuonna 1968. Sen jälkeen olen "joutunut" perehtymään 30 - 50 ohjelmointikieleen (riippuen siitä, mitkä saman kielen versiot lasketaan erikseen, ja luetaanko erilaisille keskusyksiköille ja prosessoreilla laaditut assemblerit omiksi kielikseen). Tämä on vain pieni raapaisu, ohjelmointikieliä on kehitetty useampi tuhat. Yleisessä käytössä on nykyisin ehkä parikymmentä kieltä.

Totesin aiemmin, että konetekniikka on keksinyt ratkaisun koneiden suunnittelun tarpeisiin: vakioidut ja yleiskäyttöiset osat. Vastaavaa alettiin kehittää ohjelmointia varten. Alettiin laatia yleiskäyttöisiä ohjelmia usein tarvittaville samankaltaisille tehtäville. Niitä sanottiin proseduureiksi, ja vastaavaa ohjelmointitekniikkaa proseduraaliseksi ohjelmoinniksi. Mutta ohjelmat joutuvat ottamaan kantaa myös dataan: sen tyyppeihin, rakenteeseen ja niille ominaisiin käsittelytapoihin. Syntyi niin sanottu olio-ohjelmoinnin käsite (object oriented programming) ja sitä tukevia kieliä. Tunnetaan myös täysin toisenlaiseen ajatteluun perustuvat funktionaaliset kielet ja logiikkakielet, mutta niiden käyttö on jäänyt vähäiseksi. 

Ohjelmoinnista ei siten tullut yhtä selkeää modulaarista suunnittelua kuin konesuunnittelusta. Pikemminkin ohjelmointi on säilyttänyt individualistisen käsityöleiman. Se on enemmän tai vähemmän yksilöllistä puurtamista, missä henkilökohtaisilla kyvyillä on suuri vaikutus tehokkuuteen. 

Ohjelmoinnin nykytila merkitsee muun muassa sitä, että kynnys aloittaa ohjelmointi on pysynyt matalana, ohjelmoijista suuri osa on suorastaan itseoppineita. Niin sanottu ketterä ohjelmointi (agile programming) koettaa ratkaista ohjelmoinnin ongelmia ryhmätyötekniikalla. Se saattaa olla tehokasta, mutta ohjelmien läpinäkyvyys pysyy heikkona. Toisin sanoen, alkuperäisen tiimin ulkopuolisen on vaikea ymmärtää ohjelman toimintaa tai korjata sitä.

Nykyisin ei enää puhuta ohjelmistokriisistä, mutta se on edelleen tosiasia. Ohjelmointityön tehottomuus ja laajojen ohjelmistojen laatu- ja ylläpito-ongelmat ovat informaatiotekniikan hyödyntämistä vakavasti haittaavia asioita. Odotan mielenkiinnolla teknologista innovaatiota, joka tulee ratkaisemaan tämän ongelman. Luulen, että se tulee aivan eri suunnasta, mistä sitä odotamme. Muutenhan se olisi jo keksitty.

*) Fortran=formula translator
    Algol=algorithmic language
    Cobol=common business oriented language
    Basic=beginner´s all-purpose symbolic instruction code

Amatöörit asialla ?

Sähköinen resepti. Potilastietojärjestelmä. Sähköisen äänestyksen kokeilu. Presidentti Obaman sairausvakuutusuudistus. VR:n matkalippujen myyntisovellus. Esimerkkejä epäonnistuneista ohjelmankehitysprojekteista on helppo poimia otsikoista. Mutta julkisuus on vain jäävuoren huippu. Yksityisellä puolella epäonnistuneet hankkeet haudataan talon sisällä, harvoin niitä lähdetään repostelemaan mediassa.

Ja isojakin ruumiita tulee. Ohjelmisto-ongelmat kaatoivat Nokian matkapuhelinliiketoiminnan. Nokian mukaan he eivät älynneet olla ohjelmatalo. Väite on naurettava. Nokian käyttöjärjestelmätiimi oli kymmenen kertaa isompi kuin se porukka, joka ohjelmoi Androidin Samsungin puhelimiin.

Mikä insinöörejä riivaa? Miksei ohjelmia osata tehdä - vai onko vika projektinhallinnassa? Selityksiä voisi tarjota, koetan tarjota kolmea: 1. projektit annetaan osaamattomille amatööreille. 2. projektien päätöksenteko on ammattitaidotonta, 3. insinööritaidon perinteistä ei osata ottaa oppia.

Vaikeat projektit joutuvat amatöörien käsiin?

Kokeneet projektitalot onnistuvat projekteissaan, koska niiden parhaat asiantuntijat pystyvät tehokkaaseen ja toimivaan projektijohtamiseen. Tähän ei voi väittää vastaan, mutta katsotaan tilannetta tarkemmin. Miksi sitten kokeneet projektitalot eivät tee näitä valtakunnan kriittisiä projekteja. Syy voin olla seuraava. Jos projekti on niin sanotusti helppo, sen määrittely onnistuu hyvin ja projektihenkilöstö pitää projektin hallinnassa. Projektista saadaan sen kuluessa täsmällisesti etenevä ja ennusteen mukaisesti tarkentuva kuva. Oikeastaan jopa projektin johtaminen on silloin jo suorastaan turhaa. Projektin kulkuhan arvattiin oikein, ja se olisi onnistunut muutenkin ja pienemmin hallintokuluin. 

Ja sitten se iso mutta. Asiansa osaava projektitalo osaa valita projekteja, jotka ovat hallittavissa, tai ne osataan muuttaa hallittaviksi. Hyvä projektitalo osaa myös rajata vastuunsa, niinpä se ei ota niskoilleen projekteja, joiden onnistuminen on epävarmaa. Joten hankalat projektit todella joutuvat usein amatöörien käsiin. Amatöörit saavat vastuulleen juuri niitä hankkeita, joita on hankala määritellä niin selkeästi, että ne voitaisiin edes siirtää projektiammattilaisille.

Tietysti on myös totta, että ohjelmistoalalla amatöörin ja ammattilaisen raja on häälyvä. Raja on häälyvä ohjelmistofirmojen välillä, mutta se on häälyvä myös niiden sisällä. On vaikea selvittää, kuka osaa ja mitä osaa ja mikä firma osaa. Se kun riippuu myös kontekstista - eli millaisesta ohjelmasta onkaan kysymys.

Ei osata johtaa eikä tehdä järkeviä päätöksiä

Uskomme mielellämme, että johtaminen perustuu johdettavien asioiden tuntemiseen. Jossain määrin se pitää paikkansa, ja se pitää paikkansa erityisesti johtamisen alemmilla tasoilla, eli kun päätetään projekteista ja johdetaan niitä. Ohjelmistopuolella sisältöjohtaminen on kuitenkin erityisen vaikeaa. Ohjelmistotekniikka on kehittynyt suuntaan, jossa dokumentointi ja strukturointi on kustannussyistä minimoitu. Ohjelmointi on tiimien sisäistä intensiivistä sosiaalista toimintaa, ulkopuolelta sitä on vaikea edes tarkkailla, saati ymmärtää.

Niinpä, kun pitäisi tehdä tärkeitä ohjelmia tai julkishallinnon ohjelmia, päätöksenteko siirtyy nopeasti organisaatiossa ylöspäin, tasolle, jossa sisällön osuudesta ei enää voi juuri puhua. Ja tulokset puhuvat puolestaan.

Insinööriperinne unohtui

Julkisuudessa esillä olleilla ohjelmistoilla on eräs yhteinen piirre. Ne toimivat osana ihmisten johtamia järjestelmiä. Teknisin termein, kyseessä ovat monimutkaiset ihminen - kone- systeemit. Tällaisten järjestelmien määrittely ja suunnittelu ovat vaativia, koska erilaisia toiminnan ja väärän toiminnan mahdollisuuksia on niin paljon. Tämä on traagista, koska tietokoneilla olisi niin suuria mahdollisuuksia parantaa ja tehostaa palveluja. Ongelma on erityisesti siinä, että kehitettävillä järjestelmillä ei juuri ole esikuvia, ja vaikka olisi, niitä ei voisi modulaarisuuden puutteen ja lisenssiongelmien takia hyödyntää. Ohjelmien evoluutio nimittäin poikkeaa teknologian valtavirrasta. Perinteinen teknologia kootaan erillisistä osista, jotka puolestaan ovat kehittyneet vähitellen pitkän kehityshistorian kautta.

”Kerralla valmiiksi” - kehitysmalli on vaarallinen, ja huonosti modulaaristen ohjelmistojen kohdalla tilanne on erityisen paha. Ohjelmistoissa tosin jäljitellään evoluutiota vaiheittain tarkentuvan kehitysmallin avulla. Toimintamallia sanotaan - mielestäni hirtehisesti - ”ketteräksi ohjelmoinniksi”. Mutta käytännössä mallille ei anneta riittävää aikaa. Ihminen-kone järjestelmissä malli edellyttää myös käytön aloittamista siinä vaiheessa, kun järjestelmä on vielä epäkypsä. Sitä vain ei voi välttää - joten ohjelmista saatavat ikävät kokemukset ovat tulleet jäädäkseen.

Olen pohdiskellut kehitysprojektien ongelmia - myös laajemmin kuin ohjelmien osalta - tarkemmin kirjassani ”Projektitoiminnan musta kirja”.