Luettelo tarkisti itsensä, ei tiedostoja

Luettelossa oli 886 riviä. Kansiossa oli 821 tiedostoa.

Kumpikaan luku ei ollut virhe. Luettelo oli tarkistettu ja se oli läpäissyt tarkistuksen moitteetta, ja kansiossa oli juuri niin monta tiedostoa kuin siellä oli. Ero oli 65 riviä, ja ne osoittivat paikkaan, jossa ei ollut mitään.

Jokaisessa yrityksessä on lista, joka lupaa jotain

Tämä on tietotyön tavallisin rakenne: Lista, joka kertoo, missä jokin on. Kuvapankin hakemisto, tuotekuvien luettelo, sopimusliitteiden rekisteri, laskujen tositteet, tai se kontekstitiedosto, johon on kirjattu, mistä kone löytää minkä. Lista ei ole itse työ. Lista on lupaus siitä, että työ on tehty.

Kun joku kysyy, onko lista kunnossa, siihen vastataan katsomalla listaa. Se on luonteva tapa, ja se on väärä tapa.

Mitä oikeasti tein

Rakensin markkinointia varten kuva- ja videokirjaston, jotta toistuva julkaisutyö ei alkaisi joka kerta tiedostojen etsimisestä. Putki on suoraviivainen: Aineisto haetaan lähteestä, ihminen hyväksyy, mitä otetaan mukaan, hyväksytyt ladataan, ja jokaisesta tiedostosta kirjataan luetteloon tarkistussumma ja tieto siitä, mistä se tuli.

Luettelo myös validoitiin. Tarkistus katsoi, että rivejä on 886, että tarkistussummat ovat kaikki eri, että polut ovat kaikki eri ja ettei kaksoiskappaleita ole yhtään. Jokainen kohta meni läpi.

Sen jälkeen ajoin toisen tarkistuksen, joka ei katsonut luetteloa lainkaan. Se otti jokaisen rivin polun ja kysyi käyttöjärjestelmältä, onko siinä paikassa tiedosto. Vastaus oli 821.

Eheä luettelo voi kuvata tyhjää

Kaikki tarkistukset, jotka olin kirjoittanut, vertasivat luetteloa itseensä. Rivien määrä, summien erilaisuus, polkujen erilaisuus ja kaksoiskappaleiden puute ovat luettelon sisäisiä ominaisuuksia. Ne kertovat, että luettelo on hyvin muodostettu. Ne eivät kerro mitään siitä, vastaako luetteloa mikään.

Olemassaolo on se yksi ominaisuus, jota lista ei voi todistaa itsestään. Sen tarkistaminen vaatii kysymyksen, joka menee listan ulkopuolelle, ja juuri sitä kysymystä ei yleensä ole kirjoitettu mihinkään. Se tuntuu liian itsestään selvältä kirjattavaksi.

En korjannut eroa

Ilmeinen seuraava liike olisi ollut siistiä tilanne: Poistaa ne 65 riviä, joiden tiedostoa ei ole, tai ladata puuttuvat uudelleen. Tein kolmannen asian. Kirjasin eron projektin tilatiedostoon ja jätin sekä luettelon että tiedostot koskematta.

Puuttuva tiedosto tarkoittaa kahta vastakkaista asiaa, ja ne näyttävät täysin samalta. Joko tiedosto on kadonnut ja rivi on oikea, tai tiedostoa ei ole koskaan ollut ja rivi on väärä. Jos poistan rivit, hävitän ainoan jäljen siitä, että ne aineistot kuuluivat kirjastoon. Jos lataan puuttuvat uudelleen, saatan palauttaa juuri ne, jotka joku on tarkoituksella poistanut.

Tämä ei ole teoreettinen huoli. Samassa projektissa korjausrutiini ehti kerran tulkita puuttuvat tiedostot aukoiksi ja alkoi täyttää niitä, vaikka ne olivat ihmisen tekemiä hylkäyksiä. Ajo peruttiin, ja sääntö kirjoitettiin auki: Puuttuva tiedosto on päätös, ja sen palauttaminen vaatii erillisen vahvistuksen.

Yksi tarkistus, joka kannattaa lisätä

Ota yksi lista, johon jokin automaatio luottaa. Älä katso sitä. Laske kaksi lukua: Montako riviä listalla on, ja montako niiden nimeämää asiaa on oikeasti olemassa. Jos luvut eroavat, olet löytänyt jotain, mitä yksikään nykyinen tarkistus ei kerro sinulle.

Ja ennen kuin korjaat eron, päätä, kumpi puoli saa olla väärässä. Se päätös on paljon helpompi tehdä nyt kuin siinä hetkessä, kun ero löytyy. Kun tekoäly otetaan käyttöön toistuvaan tietotyöhön, se nojaa näihin listoihin, eikä se osaa epäillä niitä puolestasi.