Kun ohjelmistotuotanto ei riitä

Kirjoitus on julkaistu Tietojenkäsittelytiede, kesäkuu 2000, ss. 10-14. Lehden toimituksen tekemät pikkukorjaukset eivät näy tässä versiossa.

Joskus eteen tulee niin haastava ohjelmisto-ongelma, että yrityksen oma osaaminen ei riitä sen ratkaisemiseen. Voiko apua hankkia yliopistoista, vai elävätkö ne ihan eri maailmassa?

Tositarina

Sain hiljattain sähköpostiviestin, jossa pyydettiin apua sopivan algoritmin suunnittelemisessa. Algoritmin tehtävänä oli löytää paras kokoonpano usean mahdollisen joukosta. Lähettäjä oli itse keksinyt vain eksponentiaalisia algoritmeja, ja piti niitä aivan liian hitaina. Tehtävä vaikutti sellaiselta, että mikään yksioikoinen ratkaisu ei toimisi, mutta huolellisesti tilanteeseen sovitettu haaraudu-ja-rajaa -hakualgoritmi olisi luultavasti ratkaissut sen riittävän tehokkaasti.

Ikävä kyllä viesti kuvasi algoritmin tehtävän niin sekavasti, että en saanut selville, mitä tarkalleen ottaen haluttiin. Viestin sisällön ja sovellusalaa koskevan yleissivistykseni pohjalta koetin arvata, mitä lähettäjä tarkoitti "kokoonpanolla" ja muilla käyttämillään termeillä. Tein tarkentavia kysymyksiä, ja vaihdoimme viestejä jonkin aikaa. Lopulta muotoilin tehtävän matemaattisesti, lähetin sen kommenttien kera keskustelukumppanilleni ja kysyin "tätäkö tarkoitit?" Vastauksesta kävi ilmi, että nyt hänellä meni sormi suuhun.

Vaihdoimme viestejä jonkin aikaa, mutta tehtävän yksityiskohdat eivät valjenneet. Tämä oli kummallista, sillä sovellusalue oli minulle ja itse asiassa kenelle tahansa tuttu. Vaikutti siltä, että lähettäjä ei kerta kaikkiaan kyennyt erittelemään tehtävässään esiintyviä perusosia, niiden eriluonteisia yhdistelmiä ja suhteita eikä ratkaisun hyvyyden määräytymistapaa. Kyllä hän varmaan tunsi ne kaikki, mutta hän ei saanut annettua jokaiselle omaa nimeään, jota olisi sitten johdonmukaisesti käyttänyt. Niinpä en sillä kertaa voinut auttaa.

Määrittelemisen luonnottomuus

Osata tehdä ja osata kertoa miten jokin tehdään ovat aivan eri asioita. On paljon helpompaa ajaa polkupyörällä kuin määritellä miten se tapahtuu. Vaikka en osaa kuvailla Suomen karttaa ollenkaan tarkasti, tunnistan sen silmänräpäyksessä kun näen sen.

Muun muassa tietämysjärjestelmien tekijät ovat törmänneet tähän ilmiöön. Kun he ovat yrittäneet pelkistää pätevien erikoislääkärien asiantuntemuksen joukoksi sääntöjä, on menestys ollut vaatimaton. Kysymykseen "miksi päättelit taudin olevan se-ja-se" saattaa tulla vastaukseksi "koska oireet olivat nämä-ja-nämä". Niinpä tekijä kirjaa säännön "JOS nämä-ja-nämä NIIN se-ja-se". Kohta tulee uusi potilas, jolla on samat oireet, mutta diagnoosi onkin toinen. Kysymykseen "miksi" tulee vastaukseksi eroavuus jossain asiassa, josta ei ensimmäisellä kerralla puhuttu mitään. Lääkärit eivät kerta kaikkiaan osaa kertoa kaikenkattavasti, miksi he päättelevät hankalissa tapauksissa niin kuin päättelevät. Ei heitä pidä tästä syyttää, se kuuluu ihmisen rakenteeseen.

Sama pätee ohjelmistojen toteutuksessa. Ohjelmoija, joka tuntee sovellusalueen hyvin, osaa vastata ohjelman toivottua toimintaa koskeviin kysymyksiin sitä mukaa kuin ne nousevat ohjelmoinnin aikana esiin. Siitä huolimatta hän ei ehkä osaisi luetella samoja kysymyksiä vastauksineen ennen ohjelmoinnin aloittamista. Vaikka osa kysymyksistä on helppo tunnistaa etukäteen, on vaikeaa ajatella niin pitkälle niin tarkasti, että osaisi ennakoida ne kaikki. Siinäkin tapauksessa, että kysymyksistä olisi valmis lista, voi jokin niistä liittyä sen verran erikoiseen tilanteeseen, että sen hahmottaminen on työlästä. Mitä leikepöydälle tulee jäädä, jos heti leikkauskomennon jälkeen annetaan komento "peruuta"? Mitä lukkiutumattomien jarrujen tulee tehdä, jos auton etupyörät pyörivät vastakkaisiin suuntiin?

Tästä seuraa, että ohjelmistoja ei käytännössä tehdä kovin tiukasti ideaalin "määrittele -- suunnittele -- toteuta -- testaa" mukaisesti. Määritelmiä ja suunnitelmia toki tehdään, mutta ne ovat usein vain luonnoksia, joista puuttuu paljon olennaista, ja joissa saattaa olla suoranaisia ristiriitaisuuksia. Puuttuvat seikat täydennetään ja ristiriitaisuudet korjataan toteutus- ja testausvaiheissa. Määritelmiä ja suunnitelmia ei kukaan muista päivittää ajan tasalle. Yhteisprojekteja varten teollisuudesta saamieni spesifikaatioiden jälkeenjääneisyys on joskus ollut todella turhauttavaa!

Talon omat ohjelmoijat ovat yleensä tavalla tai toisella oppineet tuntemaan yrityksen tuotteet niin hyvin, että ymmärtävät, mitä ovat ohjelmoimassa. Niinpä määritelmien luonnosmaisuus ei yleensä ole hirvittävä ongelma. Ihan aina ei tilanne kuitenkaan ole näin hyvä. Vaikeuksia syntyy, kun suunnitelmasta tulisi keskustella ulkopuolisten tahojen kanssa, tai kun ollaan luomassa jotain niin uutta, että yrityksen sisälläkään ei vielä oikein kunnolla ymmärretä mikä se on.

Huono ja hyvä yhteistyö

Tarve keskustella ulkopuolisten kanssa voi syntyä esimerkiksi silloin, kun yrityksen oma osaaminen ei riitä jonkin erityisongelman ratkaisemiseen. Koska olen ohjelmoinnin teoreettisiin kysymyksiin erikoistunut professori, ovat omat vähäiset yrityskontaktini olleet enimmäkseen tässä ryhmässä.

Pahimmassa tapauksessa yhteistyöhanke on alkanut siten, että ensin olisi pitänyt allekirjoittaa ankara vaitiolosopimus, ja sitten laitokselle olisi kuskattu hyllymetreittäin mappeja jotka pitää säilyttää vähintäänkin kassakaapissa. Tutkijaparkojen olisi pitänyt mappikasan avulla ennätysajassa opiskella tilaajan tuote, tunnistaa ongelma ja ratkaista se. Yrityksen nimeämän yhteyshenkilön olisi ehkä saanut kiinni seuraavassa kuussa, jos sattuisi olemaan jotakin kysyttävää. Vaan eipä vastauksista olisi ollut juuri mitään hyötyäkään, sillä hän ei tunne muita teknisiä termejä kuin yrityksen ihkaoman slangin mukaiset.

Yhteistyö vaatii yhteisen kielen. On kohtuutonta vaatia --- eli bisneskielellä sanottuna liian kallista ---, että yliopisto-osapuoli opettelisi pientä yhteishanketta varten yrityksen tuotteen, kielen ja kulttuurin. Meneehän yritykseltä itseltäänkin monta kuukautta, ennen kuin juuri palkattu tulokas on saatu opetettua talon tavoille.

Paljon hyödyllisempää olisi, jos yrityksessä edes joku opettelisi kutsumaan tavoitefunktioita, tekstialkioita ynnä muita niillä nimillä, joilla oppikirjatkin niitä kutsuvat. Sekä myöhempi yhteistyö että omatoiminen tiedon haku helpottuisivat. Yliopisto-osapuoli voi toki auttaa oikeiden käsitteiden tunnistamisessa ja nimeämisessä, ja pitkässä yhteistyösuhteessa oppia yrityksen omaakin kieltä. Mutta yhteistyöhanke on tuomittu tuhoon, jos yritys ei tule yhtään vastaan, niin vaivalloista kuin se onkin.

Myös vaitiolosopimus ja hyllymetreittäin mappeja on näennäisestä helppoudestaan huolimatta väärä tapa. Yrityksen ulkopuolisen henkilön on lähes mahdotonta löytää olennaiset asiat mappipinosta kohtuullisessa ajassa, mikäli kaikki tärkeä edes on mukana ja ajan tasalla! Yrityksenkin kannalta on arveluttavaa, että sen dokumentaatiota on ulkopuolisten hallussa.

Parempi olisi, että joku yrityksen sisällä tunnistaisi ongelman, karsisi sen kannalta epäolennaiset tekijät pois, ja esittäisi ongelman ytimen yliopisto-osapuolelle. Työlästähän se on, mutta silloin yrityksen oma ymmärrys ongelmasta ja sen ratkaisusta paranee, eikä yhteistyökumppanille tarvitse luovuttaa niin paljon luottamuksellista tietoa.

Toinen tositarina

Minulla oli hiljattain hyvin myönteinen yhteistyökokemus, joka havainnollistaa edellä sanomaani. Tällä kertaa toisenakin osapuolena oli julkista tutkimusta tekevä taho, mutta juuri siksi voin kertoa tästä tapauksesta julkisesti. Ryhmä täkäläisiä signaalinkäsittelyn tutkijoita halusi selvittää tiettyjä asioita eräistä suodattimista. He tiesivät, että kyseiset suodattimet voidaan ymmärtää myös äärellisinä automaatteina, ja he halusivat löytää pienimmät mahdolliset suodattimiaan vastaavat automaatit. He arvelivat, että tutkimusryhmässäni saattaisi olla tähän sopivaa tietoa.

Vaikka samassa Tietotekniikan osastossa olemme molemmat, kesti yhteisen kielen löytäminen jonkin aikaa. Onneksi he onnistuivat selittämään asiansa ilman, että minun tarvitsi opiskella kaikki mahdollinen signaalinkäsittelystä. Omasta puolestani yritin käyttää heille tuttuja merkintöjä missä vain mahdollista. Matkan varrella minulle selvisi moni alussa hämärä asia, kuten se, että heidän automaattinsa eivät ole mitä tahansa, vaan ne ovat aina deterministisiä, kaikki tilat ovat hyväksymistiloja, ja sekä syöte- että tulosaakkostossa on kaksi alkiota.

Ja meillä oli tietoa äärellisten automaattien minimoinnista! Meillä oli jopa ohjelma, joka pystyi sivutuotteenaan sen tekemään, vaikka se oli alun perin tehty toiseen tarkoitukseen. Yhteisissä keskusteluissa löysimme sopivan tavan esittää suodattimista peräisin olevia automaatteja ohjelmallemme (mm. tulosaakkosto piti hävittää). Signaalinkäsittelijät tekivät pienen liitoskappaleen omiin ohjelmistoihinsa, tekivät mittauksensa, ja olivat tyytyväisiä.

Mutta tarina ei loppunut tähän. Olen tutkimustyöni vuoksi oppinut joissakin tapauksissa tunnistamaan rajatta kasvavasta numerosarjasta sen tuottavan kaavan. Niinpä pyysin heiltä mittaustulokset kokeillakseni, purisivatko keinoni niihin. Osalle numerosarjoja kaavat todella löytyivät, ja heidän tyytyväisyytensä kasvoi.

Eräs numerosarja piti minua pilkkanaan: se seurasi aluksi kauniisti siistiä lakia, mutta sitten vääntäytyi siitä väkisin eroon aivan mittausaineiston rajoilla. Yrittäessäni ymmärtää sarjan kulkua tajusin yhtäkkiä osaavani johtaa ja todistaa sen. Niinpä saatoin antaa yhteistyökumppaneilleni kokeellisten kaavojen lisäksi yhdelle tärkeälle suodatinluokalle teoreettisesti johdetun, lopullisen ja sitovan vastauksen todistuksineen. En tiedä, onko liioittelua sanoa, että he olivat melkein haltioissaan. Itse olin puolestani hyvilläni, kun sain sovellettua keräämiäni ohjelmia ja osaamista itselleni aivan uudella alueella. Ja sainhan myös tutkijan palkinnon, eli uuden julkaisun luettelooni (ja vieläpä harvinaisen helpolla).

Käsitteiden muovaamisen taidot

Onnistunut yrityksen ja yliopiston välinen yhteistyö siis edellyttää, että yrityksessä on kykyä ja halua kaivaa ratkaistavan ongelman kannalta olennaiset tiedot esiin yrityksen tietomassasta, karsia epäolennaisuudet pois ja esittää ongelma yhteisellä kielellä. Yliopisto voi auttaa, mutta ei ottaa tätä kokonaan vastuulleen.

Ikävä kyllä tämä on juuri sitä työtä, jonka totesin ihmisille luonnottomaksi. Mutta ei se silti mahdotonta ole, se vain vaatii erilaisia taitoja kuin arkielämä ja yritysten rutiinityö. Tutkijat tekevät sitä joka päivä. Se onnistuu, jos tekijä on harjaantunut abstraktien käsitteiden tunnistamiseen ja erittelyyn, niiden välisten suhteiden analysointiin, ja kaiken tämän sanoiksi, kaavoiksi tai kaavioiksi pukemiseen. Tietysti tekijän täytyy myös ymmärtää sovellusalue kunnolla, muuten saattaa tulla muodollisesti oikeita määritelmiä, joiden sisällössä ei ole järjen häivää. Juuri siksi abstrahoinnin osaamista pitää olla yrityksen puolella edes sen verran, että osataan lukea yliopistolaisten hengentyön tulokset ja varmistaa, että he ratkaisevat oikeaa ongelmaa.

Aiemmin pidettiin itsestään selvänä, että yliopistotasoisen tutkinnon suorittanut osaa muodostaa ja analysoida käsiterakennelmia omalla alallaan. Ohjelmistotyössä tämä ei ikävä kyllä päde. Kun ala oli uusi, ei vielä täysin tiedetty, minkälainen teoria on käytännön ohjelmistotyön kannalta hyödyllisintä. Osa silloisista valinnoista osui oikeaan, kuten tietorakenteet ja algoritmit. Toiset ehdotukset taas osoittautuivat epäonnistuneiksi, esimerkkinä vaikka heikoimmat esiehdot. Viime aikoina ohjelmistotyön opetuksen muutoksia on eniten ohjannut kiire saada paljon uusia käytännön ammattilaisia työmarkkinoille. Taustateorian opetuksen kehittäminen on jäänyt vähemmälle huomiolle.

Matematiikan rooli

Melkein kaikilla tekniikan ja luonnontieteiden aloilla käytetään matematiikkaa vaikeiden asioiden hallitsemiseen. Pitkään kuviteltiin, että se matematiikka, jota perinteisesti opetetaan tuleville fysiikoille ja insinööreille tyydyttää myös tietojenkäsittelyn ammattilaisten matematiikan tarpeet. Ehkä lisäksi tarvitaan lyhyt algoritmimatematiikan kurssi. Tämä ajatusmalli vaikutti muun muassa ACM:n ja IEEE:n noin kymmenen vuotta vanhaan tietojenkäsittelyalojen koulutusohjelmasuositukseen.

Vähän kerrassaan on kuitenkin huomattu, että sellainen matematiikka on ohjelmistotyössä jokseenkin hyödytöntä. Tietojenkäsittelyalalla tarvitaan aivan toisenlaista matematiikkaa kuin fysiikassa, elektroniikassa ja rakennustekniikassa. Differentiaaliyhtälöillä ei ole juuri mitään tekemistä niiden abstraktien käsitteiden kanssa, joiden parissa ohjelmistoammattilaiset päivittäin puuhaavat. IEEE ja ACM ovat juuri tästä syystä nostaneet vielä keskeneräisessä uudessa suosituksessaan tietojenkäsittelyn oman matematiikan tukiaineen paikalta yhdeksi ylimmän tason pääryhmäksi, ja vieläpä määritelleet sen kaikille välttämättömäksi suuntautumisesta riippumatta.

Tietojenkäsittelyn matematiikassa on paljon työkaluja, joilla ohjelmistotyössä jatkuvasti vastaan tulevia käsitteitä voi ryhmitellä ja jäsentää, ja niiden suhteita ilmaista: joukot, kuvaukset, isomorfismi, bisimulaatio, BNF, jäsennyspuut, denotationaalinen semantiikka, O-Omega-Theta-merkinnät, luokkainvariantti, tilakone, rakenteellinen induktio ja niin edelleen. Jo se, että oppii ymmärtämään niistä useimmat, harjaannuttaa ajattelemaan täsmällisin käsittein. Aika moni saattaisi oppia käyttämään niitä omien ajatustensa ilmaisemisen ja analysoinnin työkaluina, jos niitä opetettaisiin ohjelmointiin liittyvien sovellusten avulla, eikä kaikesta irrallaan olevana abstraktina matematiikkana. Kaikki eivät sitä oppisi, mutta ei kaikkien tarvitsekaan.

Niinpä uskon, että viisaammin suunniteltu matematiikan opetus antaisi hyvät valmiudet käsiterakennelmien muodostamiseen ja analysointiin. Lisäksi se loisi tukevan pohjan, jonka varassa taitoja voisi edelleen kehittää myöhemmillä kursseilla.

Ikävä kyllä ohjelmoinnin oman matematiikan opetuksen kehittämistä ovat jarruttaneet yliopistojen sisäiset syyt sekä se, että teollisuudessa on perinteisesti suhtauduttu nyrpeästi ohjelmoinnin teorian opetukseen. Halutaan täsmäkoulutusta, mutta se on lyhytnäköistä. Laajempi teoreettinen yleissivistys auttaisi sopeutumaan tulevaisuuden tekniikoihin, joten henkilökunnan osaaminen ei vanhenisi tekniikan vaihtuessa. Se auttaisi myös arvioimaan eri teknologioiden etuja ja haittoja teknologiastrategisten päätösten pohjaksi.

Sitäpaitsi huipputuotteen jujun keksiminen vaatii huippuosaajan. Kymmenen vuotta vanhassa kirjassa "Tietokone Suomessa 30 vuotta" kerrotaan, miten käyttöjärjestelmien perusteiden opetusta pidettiin aikanaan järjettömyytenä näin pienessä maassa. Yliopistoja jopa estettiin hankkimasta siihen sopivia koneita. Olisi kuulemma pitänyt keskittyä pelkästään sovellusten kehittämiseen. Mitähän Linus Torvalds sanoisi tähän?

Formaalit menetelmät

On ehdotettu, että ohjelmistotyön laatuongelmat saataisiin ratkaistua ottamalla käyttöön niin sanottuja formaaleja spesifiointimenetelmiä ja muita formaaleja menetelmiä. "Formaali" tarkoittaa tässä tapauksessa sekä syntaksin että semantiikan osalta matemaattisen täsmällisesti määriteltyä.

Matemaatikkojen tavasta määritellä asioita formaalit menetelmät eroavat siten, että matemaatikot eivät yleensä viitsi määritellä käyttämiensä merkintöjen syntaksia ja staattista semantiikkaa täsmällisesti, ja heidän merkintätapansa tukevat huonosti isojen määritelmien hallitsemista. Lisäksi jokainen formaali määrittelymenetelmä on sitoutunut omaan määrittelyparadigmaansa, mutta matematiikka sallii vapaan yhdistelyn. Formaaleilla menetelmillä kirjoitetut määritelmät ovat yleensä koneellisesti luettavissa ja ymmärrettävissä. Matemaatikkojen määritelmät eivät ole. Jokainen teoreemantodistimia käyttänyt tietää, että tarvitaan uskomattoman paljon työtä, ennen kuin matemaatikkojen kaavat saadaan koneen vaatimalle täsmällisyystasolle.

Toisaalta juuri näistä syistä matematiikka on paljon joustavampaa. Siinä voidaan keskittyä olennaiseen, ja jättää rutiininomaiset tekniset yksityiskohdat hoitamatta, kun tiedetään, että ne voitaisiin hoitaa, jos haluttaisiin. Formaalit menetelmät pakottavat tarkkuuteen epäolennaisissakin seikoissa, ja niihin saattaa upota uskomattoman paljon työtä. Lisäksi matematiikka sallii kätevimmän määrittelytekniikan valinnan paljon suuremmasta joukosta kuin formaalit menetelmät.

Formaalien määrittelymenetelmien maailmanvalloitusretki on edennyt kovin hitaasti. Luulen, että siihen on hyvät syyt. Määritelmien koneellinen käsiteltävyys olisi mukava asia, mutta sen hinnaksi vaaditaan aivan kohtuuton määrä ylimääräistä koodaustyötä. Matemaattisesta määritelmästä jää helposti jotain olennaista puuttumaan, mikä tulisi varmasti formaaliin määritelmään mukaan. Toisaalta formaalista määritelmästä tulee helposti nippelitasolla tehtyjen virheiden vuoksi todelliselta sisällöltään aivan hullu, ilman että kukaan huomaa niin käyneen. Matemaattinen määrittely vaatii tietysti matemaattisen ajattelun taitoja, mutta niin vaatii myös formaali määrittely, jos halutaan mielekkäitä määritelmiä.

Uskon, että olisi paljon hyödyllisempää panostaa ohjelmistotyöhön sovelletun matematiikan opettamiseen kuin formaalien menetelmien opettamiseen. Voi hyvin olla, että kun edellinen on kunnolla tehty, ei jälkimmäistä edes tarvita, ja toisaalta uskon, että jälkimmäinen ei voi onnistua ilman edellistä. En ole kategorisesti formaaleja menetelmiä vastaan --- itse asiassa uskon niistä vielä joskus olevan suurta hyötyä esimerkiksi hajautettujen järjestelmien tarkistamisessa --- mutta niiden kanssa ei pidä liioitella. Sekä nykyinen suuri epätäsmällisyys että formaalien määrittelymenetelmien vaatima täydellinen täsmällisyys ovat huonoja vaihtoehtoja, ja optimi on jossain niiden välissä.

Mistä osaajat?

Vaikka yritys aikoisi ostaa vaativien ongelmien ratkaisut ulkoa, tarvitaan täsmällistä määrittelemistä osaavia henkilöitä silti edes sen verran, että taidot riittävät neuvottelemiseen ratkaisijatahon kanssa ja saatujen ratkaisujen omaksumiseen. Jos yritys haluaa ratkaista vaativan ongelman itse esimerkiksi tietosuojasyistä, on yrityksen sisällä oltava tietysti vielä paremmat teoriataidot. Standardointityö on erityisen hankalaa, koska siinä luodaan uutta yhteistyössä kilpailijoiden kanssa, ja lopputuloksen on oltava tarpeeksi täsmällisesti määritelty. Omien etuja vahtimiseksi on tärkeää osata analysoida jo luonnosvaiheessa tarkasti, mitä eri vaihtoehdot merkitsevät oman yrityksen kannalta.

Toivottavasti yliopistot tuottavat jo lähitulevaisuudessa suuret joukot ohjelmistoammattilaisia, jotka osaavat myös täsmällisen määrittelemisen ja analysoinnin taidot silloin kun niitä tarvitaan. Kestää kuitenkin kauan, ennen kuin he ovat ylenneet avainpaikoille.

Nopeampaa tietysti olisi kouluttaa täsmällisen määrittelemisen taitoa avainpaikoilla jo oleville. Ikävä kyllä täysin uusia ajattelumalleja on sitä vaikeampi oppia, mitä vanhempi on.

Toisaalta monilla lahjakkailla ihmisillä on sisua ja kunnianhimoa sekä vilpitön halu oppia aivan uusia asioita. He olisivat valmiita panostamaan opiskeluun, jos he saisivat siihen riittävästi aikaa ja kokisivat, että työnantaja arvostaa sitä. Yksilö, yritys ja yliopisto voisivat yhdessä sopia, mitä avainhenkilölle opetetaan. Täsmällisen määrittelyn taito voisi olla ytimenä isommassa kokonaisuudessa, jossa opiskellaan muitakin yritykselle hyödyllisiä asioita, ja haetaan yrityksen vaativille ongelmille ratkaisuja. Ehkäpä tässä olisi syy lähettää avainhenkilöitä tohtoriopintoihin?