Ketteryys ja virheiden pelko

Nuorena tyttönä koodaillessa oppi ainakin sen, että virheitä tapahtuu – ihan kaikille. Ihmisten logiikka on harvoin aukotonta. Tuotantolaatuinen koodi olikin sitten jotain ihan muuta, kuin mitä olimme korkeakoulussa tehneet harjoitustöinä. ”Olemme selvittäneet, että sinä olet koodannut tämän verkkolaitteen kellomoduulin”, ääni puhelimessa sanoi minulle. ”Mitä tapahtuu, kun vuosituhat vaihtuu?”

Kyseessä oli ensimmäinen työelämässä tekemäni ohjelmisto. ”Ei tapahdu mitään”, vastasin, ja mielessäni pyöri muistikuvia siitä, miten olin asettanut kellon vuosituhannen vaihteeseen ja katsonut, kun numerot pyörähtivät kohti nollia.

”Näitä laitteita on myyty kymmeniätuhansia, ja olemme suunnitelleet mittavan valvonnan – menetkö henkilökohtaisesti takuuseen, että laitteet toimivat myös vuosituhannen yli?” hän kysyi.

Mietin lämmöllä silloista projektipäällikköäni. Hänen ihanteenaan oli ollut vanhan ajan köydenpunoja, joka hyppäsi kirkonkellon kyytiin kun kelloa hinattiin kellotorniin takuuna siitä, että köysi kestää – jos köysi olisi katkennut, kello olisi surmannut kyläläiset mutta samalla myös köydenpunoja olisi kuollut. Olimme tehneet laitetta laatu edellä. ”Menen”, vastasin.

“To err is human – but to really foul things up requires a computer”

Muistan, miten professorini kertoi tarinaa omasta ensimmäisestä reikäkortilla olleesta ohjelmointivirheestään. Ohjelma oli jäänyt ikiluuppiin, ja seuraavana aamuna nuorta harjoittelijaa oli odottanut kokonainen huoneellinen tulostetta…

Vanhassa maailmassa oli tapana, että kukin vastasi itse töistään ja työn laadusta. Esimies oli ylin auktoriteetti, ja liian isosta virheestä saattoi joutua vaihtamaan työpaikkaa.

Vaatimus virheettömyydestä johtaa helposti peittelyyn. Vastuu sysätään muille (ei kerrottu), syytetään prosessia (ei tarkistettu), tai virhe suorastaan kielletään (ei haluta nähdä ilmiselvää asiaa, asiakas on väärässä).

Linus’s law: given enough eyeballs, all bugs are shallow

Ketterän tekemisen laatukäytännöt pohjaavat pitkälti Extreme Programming -käytäntöihin: testien automatisointiin, testien säännölliseen toistamiseen, palautteen hakemiseen (mieluiten asiakkaalta asti), uuden testitapauksen kirjoittamiseen aina kun virhe on esiintynyt, erilaisiin testaus edellä -menetelmiin, parikoodaamiseen ja parin kanssa tarkistamiseen.

Ohjelmiston laatua voi edelleen virittää luomalla joka paketin mukana automaattisesti päivittyviä teknisen velan mittareita sekä automatisoimalla testauksen ja laatuportit. Hyviä teknisen velan mittareita ovat virheiden elinkaaren pituus, virheiden korjauksen läpimenoajat, virheiden määrä, koodien osien väliset riippuvuudet, koodin kompleksisuus ja rajapintojen vakaus.

Teknisen velan lisäksi voimme puhua virheiden velasta ja testausvelasta. Ideaalisesti ketterässä DevOps-ympäristössä automaattiset tarkistukset tukevat kehittämistä niin pitkälle, että virheiden tekeminen on lähes mahdotonta – palaute on välitöntä ja mahdolliset virheet nostetaan helposti esille korjattaviksi.

Parin sijasta kuka tahansa organisaatiossa voi tarkastella koodia ja nostaa siitä esille mahdollisia huolenaiheita – Linuksen lain mukaan tarkkailijoiden määrä korreloi havaittujen ongelmien määrän kanssa.

Fail early, fail often, fail forward

On tutkittu tosiasia, että ketterät tiimit löytävät enemmän virheitä ja korjaavat virheet nopeammin. Ne myös pääsevät korkealaatuiseen, lähes virheettömään koodiin käyttämällä lyhyitä palautesyklejä, korkeaa automaation astetta, tiimin yhteistyötä ja osaavia ihmisiä. Näin virheettömän tekeminen tehdään helpoksi.

Wordin oikeinkirjoitus auttaa välttämään kirjoitusvirheitä sekunneissa, koska palaute on nopeaa ja välitöntä – entinen punakynäprosessi oli hitaampi ja saattoi viedä päiväkausia. Toki automaation tukena on edelleen hyvä käyttää punakynää, mutta fokus ja ihmisen osaksi jäävä työ on selkeästi erilainen, kuin jos oikeinkirjoitusta ei olisi jo automaattisesti tarkistettu.

Ketteryyden sijasta voidaan puhua myös anti-fragiilisuudesta, eli aletaan luoda särkymättömiä tuotteita ja palveluita. Esim. Netflix on kunnostautunut tällä saralla mittaamalla, kuinka kauan palvelulta kestää palautua totaalisesta verkkovirheestä. Netflix on myös luonut joukon automaattisia algoritmeja, jotka aiheuttavat erilaisia virheitä järjestelmiin säännöllisen epäsäännöllisesti.

Wikipediassa on kokonainen bottien armeija, joka huomaa ja korjaa artikkeleissa olevia epätäydellisyyksiä ja ristiriitaisuuksia. Osa boteista on alkanut toimia toisiaan vastaan eli korjaamaan virheitä, joita toiset botit tekevät. Lopputulos on enimmäkseen oikein, ainakin enimmän osan aikaa!

”Nobody is perfect but a team can be” – Meredith Belbin

Ketteriä ajatuksia voidaan soveltaa moneen muuhunkin ympäristöön. Minua on aina viehättänyt Belbinin tiimiroolimallin kehittäjän Meredith Belbinin ajatus siitä, että yksittäiset ihmiset ovat epätäydellisiä, mutta tiimi yhdessä voi olla täydellinen.

Jos yksittäiseltä ihmiseltä vaaditaan virheettömyyttä, se johtaa pahimmillaan suoriutumisen paineeseen, unettomuuteen ja suorituksen heikentymiseen entisestään.

Ketterästi toimivat tiimit ja työyhteisöt taklaavat tämän haasteen hyväksymällä, että virheitä tapahtuu – ja heittämällä ennen toimitusta kehiin niin monta silmäparia lopputuotosta tarkistamaan kuin mahdollista – olipa toimitus sitten asiakkaalle menevä lasku, tehty tarjous tai toimitettava koodi. Parhaimmillaan tällainen yhteistoiminta johtaa entisestään tiimihengen vahvistumiseen, yhdessä toimimiseen ja yhdessä oppimiseen.

"I have not failed. I've just found 10000 ways that won't work." - Thomas A. Edison

Ketterään kulttuuriin kuuluvat kokeilut ja niistä oppiminen. Tehdyn ja tuotetun asian tulee olla niin pieni, että virheen aiheuttama kustannus on pienempi kuin kokeilusta oppimisen tuottama arvo.

Tällöin tekemisen keskiössä eivät enää olekaan virheet, vaan miten organisaatio ja järjestelmä voi koko ajan kehittää toimintatapojaan ja yhdessä tekemistään niin, että lopputulos koko ajan hioutuu yhä paremmaksi. Samalla tiimi ja koko organisaatio pystyy kasvattamaan myös omaa osaamistaan. Fokus siirtyy oppimiseen ja palautteeseen. Kaikki uusi on arvokasta, koska se lisää jokaisen kyvykkyyksiä.

Tällaiset oppivat järjestelmät luovat parhaimpia käyttöliittymiä, tuotteita, palveluita, järjestelmiä ja työyhteisöjä.

Niin ja se alussa mainitsemani laite kellomoduuleineen muuten toimi moitteetta vuosituhannen vaihteen ylitse!