Kuolema deadlineille

Linus Torvalds on siis Linux-käyttöjärjestelmän luoja ja johtaa edelleen sen kehitystä. Kun Linus helmikuussa 1997 valmistui Helsingin yliopiston tietojenkäsittelytieteen laitokselta hän siirtyi Kalifornialaiseen Transmeta-yhtiöön töihin. Koska Linux alkoi samaan aikaan olla jo suhteellisen kypsä käyttöjärjestelmä, se sai vähitellen myös lehdistön huomiota. Linuksen siirtyminen Amerikan mantereelle teki hänestä amerikkalaiselle lehdistölle helpommin tavoitettavan ja niin ujosta nörtistä tuli yhtäkkiä koko Open Source -liikkeen kansikuvapoju.

Yksi yleisimmistä kysymyksistä siihen aikaan oli: "Milloin julkaistaan Linuxin seuraava versio?". Tähän Linuksella oli aina vakiovastaus: "Sitten kun se on valmis."

Yksi Open Source -ohjelmistokehityksen kantavia periaatteita jo ennen Linuksen mukaantuloa on ollut, että ohjelma julkaistaan sitten kun se on valmis. Mitään deadlineja ei tunneta, eivätkä tekijät suostu antamaan edes viitteellisiä lausuntoja mahdollisesta valmistumisajankohdasta.

Legendaarisessa The Cathedral and the Bazaar⁵ -kirjoituksessaan Eric Raymond ruotii tätä periaatetta. Hän tulee siihen tulokseen, että ohjelmistoprojektissa, kuten missä tahansa muussa projektissa, asetetaan tyypillisesti kolmenlaisia tavoitteita: 1) Valmiissa tuotteessa tulee olla tietyt ominaisuudet, 2) tuotteen tulee täyttää tietyt laatukriteerit ja 3) sen tulee valmistua tietyssä aikataulussa.

Näiden kolmen vaatimuksen – ominaisuuksien määrä, laatu ja aikataulu – välillä on tietty jännite. Jos esimerkiksi aikataulu on liian kireä, ei ehkä kaikkia ominaisuuksia ehditäkään toteuttamaan. Jos projektipäällikkö kuitenkin on tiukka ja pitää kiinni asetetuista tavoitteista sekä ominaisuuksien määrän että aikataulun suhteen, joutuvat työntekijät hosumaan ja laatu kärsii. Raymond tulee kuitenkin siihen tulokseen, että jos tietoisesti suostutaan luopumaan yhdestä tavoitteesta, voidaan kahden muun osalta yleensä päästä hyviin tuloksiin.

Open Source -yhteisön periaate deadlineja vastaan on tätä taustaa vasten järkevä valinta. Se on todennäköisesti yksi syy Open Source -ohjelmistojen menestyksen takana. Toisaalta se on räikeä vastakohta muussa yritysmaailmassa vallalla olevalle projektikulttuurille, jossa ei ainoastaan ole yhtä deadlinea, vaan myös monta väli-deadlinea. Joskus tuntuu jopa siltä, että suurin osa projektipäällikön tehtävistä liittyy aikataulujen suunnitteluun, aikataulujen seurantaan ja aikataulujen uudelleenarviointiin. Itse tehtävä työ onkin sitten toisarvoista.

Sain itse kokea tämän jokin aika sitten, kun osallistuin erääseen projektiin, jossa asiakkaana oli eräs suomalainen tietotekniikka-alan yritys.⁶ Ensimmäisissä palavereissa asiakas ei vielä tarkalleen edes tiennyt projektin sisältöä, vaan tarkempi vaatimusmäärittely (ominaisuuksien määrä) oli osa projektia. Heti alusta yksi asia kuitenkin tiedettiin varmasti: aikataulu. Ennen kuin edes tiedettiin mitä haluttiin tehdä, oltiin lyöty lukkoon deadline. Aikataululle oli myös "hyvin perustellut" syyt. Projekti oli pakko toteuttaa seuraavan kahden kuukauden sisään, sillä siihen käytettävät varat tulivat meneillään olevan vuosineljänneksen budjetista. En tiedä kertooko tämä jotain asioiden tärkeysjärjestyksestä kyseisen yrityksen sisällä, mutta minua se ainakin huvitti.

Projektin deadlinen lähestyessä huvitus olikin tiessään, kun myöhään sunnuntai-iltana viimeistelimme tuotettamme. Projektin päätöspalaveri saatiin kuin saatiinkin pidettyä aikataulun puitteissa, ja lasku lähetettiin vuosineljänneksen viimeisenä päivänä ja kaikki olivat tyytyväisiä. Tähänkin liittyi tosin jonkin verran itsepetosta, sillä parin kuukauden päähän sovittiin vielä yksi palaveri, jossa käytäisiin läpi kaikki asiat joita ei ehditty tehdä päätöspalaveriin mennessä, ja niitä oli kyllä aika paljon. Hyvä niin. Parempi tinkiä sitten vaikka omasta rehellisyydestään kuin laadusta. Projekti todettiin siis onnistuneeksi ja ajallaan valmistuneeksi.

Laatu ja ominaisuuksien määrä ovat yritysmaailmaan ja tuotantoon liittyviä asioita. Ehkäpä joku projektipäällikkö voi hyödyntää Eric Raymondin ajatuksia seuraavassa projektissaan. Mutta vielä tärkeämpää on ymmärtää deadlinien vaikutus meidän jokaisen omaan elämään. Deadline on monille sananmukaisesti kuolemanvakava asia. Hosumme kuin hullut ja teemme yötä myöten töitä, jotta ehtisimme saada työn valmiiksi aikataulussaan. Kuitenkin hyvin usein tämä kuolemanvakava aikataulu on täysin hatusta vedetty tai – kuten omassa tapauksessani – jonkun täysin turhan byrokraattisen pikkuseikan seuraus. Tämänkö takia me olemme niin stressaantuneita?

Linus on pyrkinyt selvittämään omaa suhtautumistaan työntekoon periaatteella, joka tunnetaan Linuksen lakina. Linuksen laki vastaa kysymykseen, miksi ihminen tekee jotain? Ensinnäkin ihminen tekee jotain säilyäkseen hengissä. Toiseksi ihminen tekee asioita sosiaalisista syistä. Ja kolmanneksi ihminen tekee asioita huvin vuoksi. Ja nimenomaan siis tässä järjestyksessä.

Linuksen laki pätee siis esimerkiksi juuri työntekoon. Ihmiset tekevät työtä ensisijaisesti siksi, että saisivat palkkarahoilla ruokaa ja katon pään päälle. Mutta jos tämä olisi ainoa tavoite, riittäisi nykyistä huomattavasti vähäisempikin työn määrä. Joku on sanonut, että jos kysymys olisi vain välttämättömän ravinnon hankkimisesta, riittäisi länsimaiselle ihmiselle tehdä pari tuntia työtä viikossa. Olemme siis tienanneet välttämättömimmän osan palkastamme jo maanantai-iltapäivään mennessä. Sitä paitsi Suomen kaltaisessa hyvinvointivaltiossa olisi todennäköisesti täysin mahdollista säilyä hengissä koko elämänsä⁷ tekemättä työtä ollenkaan. Kuitenkin ihmiset haluavat tehdä työtä. Miksi?

Ihmiset käyvät töissä sosiaalisista syistä ja huvin vuoksi. Parhaat kaverimme löydämme yleensä koulusta ja työpaikalta. Tämä on siis sosiaalinen syy. Ja yleensä ihmiset pyrkivät pääsemään sellaiseen työhön, josta he nauttivat. He tekevät siis työtään huvin vuoksi.

Mutta jos teemme työtä huvin vuoksi ja nauttiaksemme siitä, miksi sitten raadamme itsemme näännyksiin teennäisten aikataulupaineiden alla? Miksi raadamme kuin kysymys olisi edelleen elämästä ja kuolemasta? Linusin mielestä mitään järkevää syytä ei ole. Työstä kuuluu nauttia, koska sen takiahan sitä tehdään. Deadlinet ovat haitaksi sekä työn tekijälle, että itse työlle.

Linux 2.2 julkaistiin lopulta 25 tammikuuta 1999. Tämän jälkeen alkoikin arvuuttelu siitä, milloin julkaistaan seuraava versio 2.4.⁸ Nyt ollaan jo päästy versioon 2.6. Sen julkaisua lehdistö jaksoi jo odottaa rauhassa, eikä kukaan enää kysynyt Linukselta siihen liittyviä päivämääriä.

Lehdistö on oppinut jotain. Ota sinäkin oppia Linuxista. Ota rennosti ja nauti siitä mitä teet.

Kirjan "Avoin Elämä: Näin toimii Open Source" verkkoversio on luettavissa ilmaiseksi.
Halutessaan siitä on kuitenkin mahdollista, ja suotavaakin, antaa kirjailijalle pientä tippiä.