Johdantona teemaan: Therac 25. Jos olet softa-alalla, kannattaa lukea tuo. Ja ehkä muutoinkin.
Tiivistelmä niille, jotka eivät jaksaneet lukea: lääketieteellisessä hoitolaitteessa oli rinnakkaisuusbugi, jota ei löydetty huolimmatta tiukoista laatustandardeista, jotka vahtivat vääriä asioita. Seurauksena 6 ihmistä kuoli vuosina 85-87 koneen säteilytettyä heitä tappavilla annoksilla. Virheen löytäminen tai edes myöntäminen kesti absurdin kauan.
Tarinan opetus: no, niitä on monia. Laatustandardien ylläpidosta teoreettisen koulutuksen tärkeyteen ja ohjelmistoprosessien merkitykseen. Tällä kertaa kiinnostava on kuitenkin yksi tietty opetus.
Jokaisessa ohjelmassa on bugeja. Ja osa niistä on täysin käsittämättömiä.
Hyvin tehtyjen ohjelmien toiminta näyttää loogiselta ja systemaattiselta. Ohjelman käyttämät metaforat voi ymmärtää, ja sen toimintaa ennakoida. Lisäksi tiedetään, että ohjelman suoritus on tiukan deterministinen prosessi yksinkertaisetn loogisten operaatioiden suoritusta. Seutrauksena onkin helppo kuvitella, että softa olisi loogista myös käyttäytyessään väärin. Se on virhe, pahimmillaan tappava virhe, kuten Therac-25:n kohdalla huomattiin.
Ohjelman pinta on ammattilaisten huolellinen luomus, joka on suunniteltu toimimaan loogisesti ja systemaattisesti. Ohjelman sisäisen toiminnan kanssa sillä on vähän jos juuri mitään tekemistä. Kun ohjelmassa on bugi, se toimii vastoin tekijöidensä suunnitelmia. Tällöin se ei noudata mitään käyttöliittymän vihjaamaa logiikkaa. Softan näennäisen rationaalinen toiminta on rakennettu tyhjän päälle. Se on vuotava abstraktio, ja sen alta ryömii esiin Nyarlathotep.
Ihmiset, ja etenkin luonnontieteen tai tekniikan parissa puuhailevat ihmiset, ovat tottuneet ajattelemaan, että loogiselta vaikuttavan ilmiön taustalla on looginen ja systemaattinen prosessi, jota se ilmentää. Linnut laulavat saadakseen pariutumisseuraa, joet virtaavat alamäkeen ja syöpäriski kasvaa lineaarisesti suhteessa säteilykuormaan, ainakin suurilla annoksilla. Nämä ovat kaikki luonnon ilmiötä, ja luonto on rationaalinen. Softa ei ole, se on ihmisen luoma järjestelmä, jonka näennäisen loogisuuden on ihminen varta vasten (ja suurella vaivalla) rakentanut toisen ihmisen iloksi.
Mikä tahansa softa voi käyttäytyä väärin millä tavalla tahansa. Ja tämä koskee myös kaikkia koneita, jotka sisältävät softaa: puhelimia, GPS:iä, kameroita, autoja, sähkölukkoja… Virheille ei saa olettaa loogista mallia siitä, miten softan pitäisi käyttäytyä.
Virheillä on kyllä logiikkansa, mutta se on eri logiikka. Parhaat testaajat ymmärtävät sen, ja arvaavat siksi, mistä etsiä virheitä. Tuo logiikka ei liity softan tarkoitukseen, vaan sen tekijöihin. Se on inhimillisen lyhytnäköisyyden ja omahyväisyyden logiikka, jonka seuraukset ovat pohjimmiltaan pateettisuudessaan arvattavia. Ja noista ensimmäinen on huonojen ja toinen hyvien koodereiden helmasynti, joten testattavaa kyllä riittää niin kauan kun hyvän ja pahan koodin puu vaan kasvaa inhimillisessä mullassa.
ps. testatkaa se helvetin koodinne. Hommatkaa joku ammattilainen testaamaan se, ei kooderi. Ihan oikeasti, toivoo käyttäjä.
Tavallaan olen samaa mieltä tämän tekstin kanssa, mutta en oikeastaan tästä, tai ainakin tulkitsen tämän tavalla, joka saa minut pitämään sitä virheellisenä:
Virheille ei saa olettaa loogista mallia siitä, miten softan pitäisi käyttäytyä.
Softa toimii aina tarkalleen niinkuin se toimii. Se voi tosin olla – ja rinnakaisuuden tapauksessa yleensä onkin – epädeterminististä. Parhaatkaan testaajat eivät voi testata epädeterminismin tuottamia virheitä, koska epädeterminismi on määritelmän nojalla jotain, mikä tappaa testattavuuden.
(Tein yhden väitöskirjan mallintarkastuksesta, Therac-keissi on tuttu. Lisää keissejä, ja samanlaista pohdintaa: Why Software fails)
Softa toimii niinkuin se toimii, totta kai. Se on kuitenki eri asia kuin mitä tässä hain.
Se mitä yritin sanoa tuossa on sama kuin mitä yritin sanoa koko tekstillä: softan käyttöliittymän tarjoamasta loogistesta mallista ei saa päätellä miten se voi tai ei voi käyttäytyä väärin.
Innostuin kirjoittamaan tämän, kun olin enoni, joka on tekniikan tohtori, kanssa purjehtimassa (ei pudonnut veneestä) ja GPS rupesi oikuttelemaan ja näytti näkevänsä 4 satelliittia, mutta ei antanut sijaintia. Kun se lopulta antoi sijainnin, eno päätteli, että sen täytynee olla oikein, koska kerran nähtiin 4 satelliittia, ja se riittää hyvin luotettavaan sijainnin määritykseen.
Kuitenkin, mehän memme nähneet yhtäkään satelliittia, vaan ainoastaan softan ruudulle piirtämiä palkkeja. Joista ei voi virhetilanteessa päätellä oikeastaan yhtään mitään, ellei tiedä miten tämä nimenomainen softa on sisäisesti toteutettu.
Anekdootin kautta vastaukseen: tuossa nimenomaisessa lauseessa ”miten softan pitäisi käyttäytyä” viittaa siis sen käyttöliittymän metaforien ja toiminnan esittämään loogiseen malliin, ei softan toteutuksen malliin. Jos sen tulkitsee toisin, lause alkaa kieltämättä kuulostaa oudolta.
Niin, siis esität, että se abstraktiotaso, joka käyttäjälle näkyy, ei sisällä kaikkea järjestelmän toiminnan kannalta olennaista, eikä sen toiminnasta voi päätellä mitään sisäisestä toiminnasta.
Tämä on tietenkin totta, mutta GPS-esimerkissäsi on se epistemologinen ongelma, että käyttäjähän ei tarkalleen samalla logiikalla voi muutenkaan tietää, että se käyttäytyy oikein. Softa siis toimii tarkalleen niinkuin toimii, eikä sen oikeellisuuteen voi luottaa vaikka se näyttäisi toimivan oikein. Esimerkiksi emme voi tietää tällä periaatteella, että esimerkiksi laskukoneen antama laskutoimitus on oikein.
GPS:n tapauksessa pessimismisi vaikuttaa jonkinlaiselta solipsismin vastineelta, koska mielekäs ”konepellinalinen” abstraktio on, että satelliitin ’näkyvyys’ on välttämätön mutta ei riittävä ehto paikannuksen onnistumiselle ja että laite antaa paikannustietoja vain kun se onnistuu.
GPS laskee paikannusdatan neljän satelliitin signaalista – sen me tiedämme. Me emme tiedä, millainen ohjelma koneen sisällä on; sehän voi olla vaikka pelkkä satunnaislukugeneraattori! Toisaalta satelliitin ”näkyminen” ilman, että paikannus onnistuu, ei välttämättä ole toimintavirhe.
Esimerkiksi jos signaali on heikko, satelliitin olemassaolo voidaan todeta, mutta se osa viestistä, jossa paikannuksen kannalta olennainen data on, voi sisältää virheitä, jotka on havaittu, mutta ei osattu korjata. Se voi toki olla olemattakin näin, mutta edelleen, sitä ei voi mistään tietää.
Oma tulkintasi siitä, että GPS-paikannin toimisi virheellisesti, jos se näyttää neljä satelliittia muttei osaa laskea paikannusta, perustuu siis myös arvailuihin.
Kun epistemologiansa nyörittää riittävän kireälle, niin tietenkään ei voi viimekädessä tietää koskaan, mitä softa oikeastaan tekee. Mutta tämä tosiaan on vähän solipsistinen lähestymistapa.
Tilanteella, jossa softa toimii ”oikein”, s.o. kehittäjien tarkoittamalla tavalla ja sellaisella jossa se toimii ”väärin” on kuitenkin ero. Käyttöliittymän tarjoama logiikka on kuitenkin olemassa. Se on softan tekijöiden varta vasten luoma, ja heillä voidaan olettaa olleen tarkoitus ylläpitää sitä. Siksi, jos softa noin ylipäänsä on käyttökelpoinen, voi kohtuudella luottaa siihen, että se melko varmasti ylläpitää käyttöliittymäkerroksensa abstraktioita. Kun savut pääsivät jo koneesta, perusteet tälle luottamukselle ovat huomattavasti heikommat. Silti sitä intuitiivisesti tulee usein ylläpidettyä.
Eli perusteltu luottamus käyttöliittymän abstraktion pitävyyteen on luottamusta softan tekijöiden ammattitaitoon sen ylläpitämisessä, ei luottamusta siihen että se heijastaisi ymmärrettävällä tavalla konepellin alaisia käsitteitä. Siksi virhetilanteessa, jossa ammattitaito selvästikään ei riittänyt, perusteluja luottamukselle on aika paljon vähemmän (voisi jopa sanoa ei ollenkaan).
Solipsismiin asti ei siis tarvitse sortua.
GPS-esimerkin osalta olet sinänsä oikeassa (joskin tilanne jossa tietoliikenteessä on häiriö, on kyllä sekin systeemin vikatilanne). Itse asiassa oioin tuossa esimerkissä hiukan, koska en enää muistanut miten se vika tarkalleen menikään. Ei siitä sen enempää.
Ymmärrän suunnilleen mitä tarkoitat, mutta ”savut pääsevät koneesta”- tilanteet ovat softassa vähän huonosti määritelty käsite. Esimerkkisi (minun tulkintani mukaan) on siksi hyvä, että se kertoo että käyttäjä saattaa tulkita järjestelmän vikaantuneen vaikka näin ei ole.
Toisaalta käyttäjä on usein varma siitä, että virhe on sattunut vasta silloin, kun järjestelmä on totaalisen jökissä. Tällöin syntyy kuitenkin kaikenlaisia kysymyksiä. Esimerkiksi, voiko esimerkiksi käyttöjärjestelmään luottaa, jos se on kerran kaatunut?
Totta kai tämä on kaikki heuristista aproksimaatiota, ja kaikissa tilanteissa on aina virhetulkintamahdollisuus. Se on kuitenkin trivialiteetti, ellet sitten näe tähän liittyvän jotain tavanomaisesta poikkeavia virhetulkintaongelmia.
Käyttöjärjestelmän osalta sanoisin,e ttä sen kaatuessa ei voi luottaa sen ylläpitävän abstraktioitaan. Esimerkiksi ei voi luottaa siihen, että jo tallennetuksi väitetty tiedosto on oikeasti tallennettu.
Yksi oleellinen kohta jota en huomannut aiemmin painottaa on, etät puhun nyt siis tilanteesta jossa käyttäjä ei tiedä ennestään miten softa käyttäytyy juuri tietyn virheen yhteydessä. Jos on a priori tieto, että tällä tavoin kaatuessa filet on oikeasti tallennettu, sitten tämä (konepellin alainen) tieto on olemassa, eikä aiheella kannata niin kauheasti spekuloida. Mutta jos virhe ei ole tuttu, eikä softan sisuksista ole hajua, ei moiseen kannata luottaa.
Itse asiassa se, että tiedän epäillä tuoreiden filetallennusten menevät käyttiksen kaatuessa poskelleen perustuu lähinnä siihen, että tiedän jonkin verran levyajureiden sisäisestä toiminnasta. jos pelaisin pelkästään käyttöliittymän kortein, ei moista tulisi välttämättä mieleen epäillä.
Ymmärrän kyllä ilmiön josta puhut. En ole tekstistä sinänsä eri mieltä, etsin vain tässä muotoilua, joka olisi ”oikea” so. sanoisi ne asiat tavalla, jota ei voisi ainakaan yhtä herkästi ymmärtää monella tavalla.
Vuotavat abstraktiot ovat ikävä ilmiö kaikenlaiselle soveltavaan formaaliin ilmaisuun pyrkimisen kannalta. Esimerkkinäsi siis käyttöliittymä ja sen antama käsitys järjestelmän ”tilasta”.
Mutta käyttöliittymän ei yleisesti ole tarkoitus olla abstrakti(kaan) esitys siitä, mitä järjestelmä tekee, vaan sillä on vain funktionaalinen rooli. So. käyttöliittymän pitää näyttää operaatioiden tuloksesta se, mikä on käyttäjälle mielenkiintoista ja mahdollistaa operaatioiden parametrien asettaminen. (Karkeasti esittäen.) Käyttöliittymä ei siis voi, eikä sen pidä, ainakaan suoraan, esittää kaikkea.
Toisaalta tässä on se, että virhe on jotain, mitä ei teoriassa pitäisi tapahtua.
Liittyen tuohon artikkeliin, minun kokemuksen mukaan softaan ei enää niin luoteta, oma lähtökohtani on ainakin että softa bugaa joka tapauksessa ja kyse on siitä mitä sitten tehdään. Mutta tämä pätkä on edelleen erittäin osuva:
”Finally, overreliance on the numerical output of safety analyses is unwise. The arguments over whether very low probabilities are meaningful with respect to safety are too extensive to summarize here. But, at the least, a healthy skepticism is in order. The claim that safety had been increased five orders of magnitude as a result of the microswitch fix after the Hamilton accident seems hard to justify. Perhaps it was based on the probability of failure of the microswitch (typically 10^5) ANDed with the other interlocks. The problem with all such analyses is that they exclude aspects of the problem (in this case, software) that are difficult to quantify but which may have a larger impact on safety than the quantifiable factors that are included.
”Although management and regulatory agencies often press engineers to obtain such numbers, engineers should insist that any risk assessment numbers used are in fact meaningful and that statistics of this sort are treated with caution. In our enthusiasm to provide measurements, we should not attempt to measure the unmeasurable. William Ruckelshaus, two-time head of the US Environmental Protection Agency, cautioned that ”risk assessment data can be like the captured spy; if you torture it long enough, it will tell you anything you want to know.”[7] E.A. Ryder of the British Health and Safety Executive has written that the numbers game in risk assessment ”should only be played in private between consenting adults, as it is too easy to be misinterpreted.”[8]”
käyttöliittymän pitää näyttää operaatioiden tuloksesta se, mikä on käyttäjälle mielenkiintoista ja mahdollistaa operaatioiden parametrien asettaminen.
Käytännössähän oleellinen osa tätä on, että käyttöliittymä antaa käyttäjälle raskaasti vihjeitä joiden avulla muodostaa mentaalinen malli softan toiminnasta. Sillä ei tarvitse olla paljoakaan tekemistä softan sisusten kanssa, mutta jos softa on käyttökelpoinen ja toimii, operaatioiden merkityksen pitäisi olla käyttäjälle intuitiivisesti selviä. Tässä mielessä käyttöliittymä on juurikin abstraktio softan toiminnasta. Mutta joo, tämä puhuttiin kyllä jo.
risk assessment data can be like the captured spy; if you torture it long enough, it will tell you anything you want to know.
Tämä on muuten todella hieno toteamus. Ja pätee jossain määrin moneen muuhunkin dataan, jonka analyysin tuloksiin liittyy intressejä. Esimerkiksi jos tuntiseurantajärjestelmää käytetään tulospalkkauksen pohjana (projektityöaste, tms), sieltä kyllä alkaa varmasti löytyä sellaista dataa joka on tarkoituksenmukaista tuolle mittarille.
Njoo, risk assesment data eroaa kyllä siinä, että se on tulevinaan suoraan järjestelmästä, kuvaten sitä eikä siihen liittyviä inhimillisä prosesseja. Mikä on tietenkin virheellinen käsitys.