Luotettavuusvelka tekee nopeudesta vaarallista jo nyt

Agenttikehityksen suurin riski ei ole huono koodi. Se on se, että muutoksen tekeminen halpenee nopeammin kuin muutoksen ymmärtäminen.

Agenttikehityksestä puhutaan enimmäkseen nopeuden kautta. Koodia syntyy enemmän, kokeilu halpenee ja kehitys kiihtyy. Tämä hyöty on todellinen. Vähemmälle huomiolle jää se, mitä tapahtuu luotettavuudelle, kun muutoskyky kasvaa nopeammin kuin kyky arvioida vaikutuksia, testata poikkeuksia ja rajata virheiden leviäminen.

Siksi agenttikehityksestä ei pitäisi puhua vain teknisen velan näkökulmasta. Se voi kasvattaa myös luotettavuusvelkaa.

Tekninen velka näkyy rakenteessa. Koodi vaikeutuu, ylläpito hidastuu ja kehitys alkaa tökkiä. Luotettavuusvelka näkyy toisin. Muutoksia saadaan ulos nopeasti, mutta luottamus niiden turvallisuuteen ei pysy mukana. Julkaiseminen nopeutuu, samalla varmuus järjestelmän käyttäytymisestä heikkenee.

Tämä ei yleensä ala yhdestä suuresta virheestä vaan pienestä kitkan poistumisesta.

Kuvitellaan tavallinen tilanne. Agentti ehdottaa muutosta palveluun, joka käsittelee asiakastilausten hinnat ja alennukset. Muutos itsessään näyttää siistiltä. Testit menevät läpi, koska ne tarkistavat muutaman odotetun tapauksen. Katselmointi on nopea, koska koodi näyttää loogiselta ja muutos on helppo hyväksyä. Vasta tuotannossa huomataan, että yhdessä vanhassa rajapinnassa alennus lasketaan eri järjestyksessä kuin muualla. Lopputulos ei ole täydellinen kaatuminen vaan hiljainen virhe: pieni osa tilauksista hinnoitellaan väärin. Kukaan ei huomaa sitä heti, koska järjestelmä toimii teknisesti oikein. Häiriö ei synny siitä, että agentti olisi kirjoittanut täysin kelvotonta koodia. Se syntyy siitä, että muutos pääsi läpi ympäristössä, jossa testaus varmisti odotetun toiminnan mutta ei paljastanut vaikutusta riippuvuuksiin, poikkeuksiin tai vanhoihin oletuksiin.

Juuri tällaiseen tilanteeseen luotettavuusvelka viittaa.

Agenttikehityksessä ongelma ei siis ole ensisijaisesti huono koodi. Ongelma on se, että muutoksen tekeminen halpenee enemmän kuin muutoksen ymmärtäminen. Koodin tuottaminen nopeutuu, mutta vaikutusarvio, testauksen kattavuus, hyväksyntä, havaittavuus ja palautettavuus eivät kehity automaattisesti samaan tahtiin.

Siksi testaus ja testiautomaatio ovat tässä paljon keskeisemmässä roolissa kuin yleensä ymmärretään. Jos automaatio varmistaa lähinnä sen, että sovellus käynnistyy ja muutama tuttu polku toimii, se voi tuottaa enemmän turvallisuuden tunnetta kuin turvallisuutta. Agenttikehityksen maailmassa pitäisi testata aiempaa järjestelmällisemmin myös rajapintojen käyttäytymistä, poikkeustilanteita, sivuvaikutuksia ja palautumista. Ei vain sitä, toimiiko muutos suunnitellulla tavalla, vaan myös sitä, mitä muuta se saattoi muuttaa.

Tämä korostuu erityisesti vakaiksi totutuissa palveluissa. Niissä on vuosien aikana kertynyttä logiikkaa, näkymättömiä riippuvuuksia ja hiljaista tietoa, jota ei ole kirjoitettu minnekään. Niin kauan kuin muutoksia tehdään hitaasti, tämä ei aina näy ongelmana. Kun agenttikehitys lisää tahtia, samat rakenteet muuttuvat riskiksi. Silloin luotettavuusvelkaa ei synny siksi, että järjestelmä olisi uusi tai kaoottinen, vaan siksi, että vanhan järjestelmän käyttäytymistä ei enää tunneta yhtä hyvin kuin ennen oletettiin.

Tämä on erityisen tärkeä havainto tekniselle johdolle, arkkitehdeille ja kehityksestä vastaaville. Kysymys ei ole vain siitä, saako tiimi enemmän aikaan agenttien avulla. Kysymys on siitä, muuttuuko samalla koko organisaation riskiprofiili. Jos muutoksia voidaan tehdä aiempaa enemmän, mutta testauksen ja käyttöönoton käytännöt pysyvät ennallaan, nopeus ostetaan helposti luotettavuuden kustannuksella.

Siksi agenttikehityksen kypsyys ei näy siinä, kuinka monta muutosta tiimi saa ulos. Se näkyy siinä, miten hyvin organisaatio pystyy rajaamaan muutosten vaikutusalueen, rakentamaan testiautomaation oikeiden riskien ympärille ja palauttamaan muutokset hallitusti, kun jokin menee pieleen.

Se tarkoittaa käytännössä kolmea asiaa.

1. Muutokset pitää pitää pienempinä. Mitä pienempi muutos, sitä helpompi sen vaikutus on ymmärtää, testata ja tarvittaessa perua.
2. Testiautomaation pitää tarkistaa myös rajapinnat, poikkeustilanteet ja sivuvaikutukset. Pelkkä odotetun polun läpäisy ei riitä, jos todelliset riskit syntyvät järjestelmien välissä.
3. Käyttöönotot pitää suunnitella palautettaviksi. Ei vain onnistuviksi, vaan myös hallitusti peruttaviksi silloin kun jokin menee väärin.

Tekninen velka hidastaa kehitystä myöhemmin. Luotettavuusvelka tekee nopeudesta vaarallista jo nyt.

Siksi agenttikehityksen tärkein kysymys ei ole, kuinka nopeasti koodia saadaan tuotettua. Tärkeämpi kysymys on tämä: kehittyvätkö testaus, hallinta ja palautumiskyky yhtä nopeasti kuin muutoskyky?