Olen viime aikoina lukenut Nassim Talebin mainiota kirjaa Antifragile, joka tuo esille uuden käsitteen nimeltä “epähauras”. Käsitteelle ei ole olemassa muuta englanninkielistä sanaa, kuten ei myöskään suomenkielistä. Käyttäkäämme siis termin “antifragile” suoraa suomennosta “epähauras”. Ihmisiltä kysyttäessä hauraan vastakohtaa, ovat yleiset vastaukset “kestävä”, “sitkeä” tai “robusti”. Mutta siinä missä haittavaikutukset vaikuttavat hauraaseen negatiivisesti, robusti kestää niitä, ja epähauras hyötyy niistä.
Aloinkin siis miettiä, millaista voisi olla epähauras ohjelmisto? Unohdetaan heti alkuunsa oppiva tai itseään korjaava ohjelmisto, sen ollessa allekirjoittaneen tietotaidon ulottumattomissa. Mikäli ohjelmisto ei itsessään voi olla epähauras, mikä onkaan tämän blogipostauksen pihvi?
Puhukaamme sen sijaan kokonaisuuksista, kuten ohjelmistoprojektista, -tiimistä tai koko sitä kehittävästä organisaatiosta. Jotta projektitiimi voisi olla epähauras, tulisi lähdekoodin olla mahdollisimman robustia. Hauras lähdekoodi on kehityksen tiellä, sillä omituiset ja kryptiset ongelmat hidastavat kehitysprosessia, ja kuluttavat kehittäjien ja lopulta kaikkien energiaa ja kärsivällisyyttä.
Käykäämme läpi kehityksen vaiheet ja kuinka ne voivat olla epähauraita.
Lähdekoodi
Mistä on robusti lähdekoodi tehty? Monen hyvän kirjan, ja useammankin kirjoituksen arvoinen aihe. Robusti lähdekoodi on helposti luettavaa ja luottavaisin mielin muutettavaa. Se on hyvin organisoitua, modulaarista ja testattua. Optimaalinen koodinpätkä tai ohjelmiston ominaisuus on irroitettu selvästi omaksi kokonaisuudekseen, ja sille on kirjoitettu selkeät yksikkö- tai jopa integraatiotestit. Tällainen lähtökohta on kehittäjälle paras, koska hän voi lähes huoletta ja hyvällä luottamuksella muuttaa koodia ja todeta sen toimivuuden.
Kuten aina, nämäkin hyvät ideat ja toimintatavat voi toki viedä liian pitkälle ja luoda lähdekoodista monimutkaisen ja raskaan. Tavoite on luoda kehittäjille mahdollisimman helpot lähtökohdat muutoksiin reagoimiseen.
Projektikäytännöt
Lienee selvää, että vesiputousmallinen projektinhallinta on haurasta. Ketteristä projektinhallintamalleista Kanban palvelee ehkä eniten epähaurasta lähestymistapaa. Sen idea lyhykäisyydessään on priorisoida tekeminen, vähentää turhan ja samanaikaisen tekemisen määrää, sekä vähentää byrokratiaa. Kun tähän lisätään tiheä tai jopa jatkuva julkaisuprosessi, saadaan reagointinopeutta ja pidetään ns. “ohjelmistovarasto” pienenä.
Ohjelmistovarasto sisältää testaamattomia ominaisuuksia, joiden tarpeellisuutta ja yleensäkin reaktiota niihin, ei tiedetä. Mitä enemmän näitä ominaisuuksia on julkaisematta, sen suurempi riski. Hyvä lähtökohta projektille onkin MVP ja Kanban. Nämä käytännöt mahdollistavat tilanteisiin reagoimisen mahdollisimman aikaisessa vaiheessa ja vievät projektia epähauraampaan suuntaan.
Tiimi ja sen jäsenet
Käsitellään kahta, aiheen kannalta oleellista ihmistyyppiä, saman skaalan ääripäistä. Riskiä välttelevät ja riskinhaluiset henkilöt omaavat molemmat oleellisia ominaisuuksia tiimin onnistumisen kannalta. Riskiä välttelevät pitävät tasaisesta ja huolellisesta sovelluskehityksestä, kun taas riskinhaluiset sellaiseen kyllästyvät. Tasapainotetussa tiimissä eri henkilöt pitävät kehityksen kulun luotettavana, kun taas toiset pitävät huolen siitä, ettei kehitys seisahdu teknisesti.
Pääasia on, ettei tiimissä ole pelkästään riskin välttelijöitä, jolloin sovellus saattaa olla robusti, mutta ei epähauras. Täysin riskitön sovelluskehitys voi johtaa stagnaatioon ja kykenemättömyyteen reagoida isoihin muutoksiin. Pelkkä riskinotto sen sijaan luo helposti hauraan sovelluksen, jos paikalla ei ole ketään kitkemässä älyttömimpiä riskejä ja ratkaisuja.
Organisaatio
Epähauras organisaatio on kaiken intuition mukaan pieni ja litteä organisaatio. Byrokratia, hierarkia ja vastuun siirtäminen ovat haurasta. Organisaatiossa tulisi olla useita yleisosaajia, tai vielä mieluummin ns. T:n muotoisia työntekijöitä. Eräs epähaurauden hyvä generaattori on yleinen avoimuus. Tällä tarkoitan sitä, että kyseinen organisaatio kertoo avoimesti virheistään, toimintatavoistaan ja työympäristöstään. Virheiden “paljastaminen” ja analysointi voi toimia nimenomaan voimistavana tekijänä, jolloin kyseessä on nimenomaan epähaurautta edistävä toimintamalli. Tällainen voi olla esimerkiksi jonkin palvelun status-sivu, joka tilanteen sattuessa sisältää analyysin, syyn ja ratkaisun kyseiseen ongelmaan.
Yhteenveto
Epähauraus ohjelmistokehityksessä ilmenee usein kilpailevien ohjelmistojen haurauden kautta. Se saavutetaan kykynä julkaista usein ja reagoida nopeasti bugeihin, virheisiin, palautteeseen ja ongelmiin. Tämä kyky on suoraan riippuvainen organisaatiosta, ohjelmistotiimiistä, käytetyistä projektinhallintamenetelmistä ja lopulta lähdekoodin tilasta ja järkevyydestä.
Huom
Tekstissä käytetyllä termillä “robusti” tarkoitetaan tässä kontekstissa vikasietoista, riippumatta vastakkainasettelusta korrektiuden kanssa.
