tiistai 6. maaliskuuta 2012

Jaettu lähdekoodin omistajuus - miksei jaettu tuoteomistajuus?

Kuulen erittäin usein ihmisten hehkuttavan kuinka maailma on parempi, mikäli kaikki versionhallinnassa oleva lähdekoodi on kaikkien muokattavissa. Projektipäälliköt ja tuotepäälliköt erityisesti ovat innoissaan siitä, että kun lähdekoodi on kaikkien muokattavissa, projekteihin ei pääse muodostumaan pullonkauloja kiireisimpien ihmisten kohdalle. Kuka tahansa projektin kehittäjä kun voi muokata mitä tahansa ominaisuutta!

Koska lähdekoodin muokkaaminen käy keneltä tahansa, niin voisiko tuoteomistaja ja projektipäällikkökin olla vain resurssi muiden joukossa. Jos yrityksessä on useampi tuoteomistaja tai projektipäällikkö, voidaanko näistä ihmisistä ottaa kuka tahansa vastaamaan tuotteita tai projekteja vaivaaviin kysymyksiin? Jos tuotepäälliköltä kysyy, niin vastaus on useimmiten ei. Eihän muut tuotepäälliköt välttämättä tunne tuotetta niin hyvin eivätkä tuotteeseen halutut ominaisuudet ole kaikkien tiedossa yhtä kirkkaasti. Projektipäällikkö puolestaan helposti toteaa, että pitäähän sitä tuntea projektin sidosryhmät ja aikataulut sekä muut vaatimukset, että voi tehdä hyviä päätöksiä. Todettakoon, että en ole tehnyt aiheesta kattavaa kyselyä ja siksi en tiedä kuinka moni tuotepäällikkö tai projektipäällikkö esittämälläni tavalla ajattelee.

Oletetaan nyt kuitenkin, että edellisessä kappaleessa esittämäni arvaukset ovat totta ja tuoteomistajat sekä projektipäälliköt eivät pidä järkevänä geneeristen tuoteomistaja- ja projektipäällikköresurssialtaiden luomista. Onko sovelluskehittäjän työ sitten niin yksinkertaista ja rutiininomaista, että kuka tahansa voi tehdä muutoksia mihin tahansa tuloksen säilyessä hyvänä? Olettavatko kaikki ei-sovelluskehittäjät näin? Olettavatko monet sovelluskehittäjät, että näin on? Miksei sovelluskehittäjän tarvitse tuntea eri ominaisuuksien taustoja tai tulevia tarpeita, jos kerran asiasta päättävien tarvitsee?

Myönnän, että suuri osa lähdekoodin kirjoittamisesta on täysin rutiininomaista ja tylsää puuhastelua, johon pystyy lähes kuka tahansa sovelluskehittäjä, mikäli välineet ovat tuttuja. Silti väitän, että rutiininomaisesta puuhastelusta syntyy hyvin nopeasti kokonaisuuksia, joita ei ymmärrä, ellei ole tekemisissä kyseessä olevan lähdekoodin kanssa tarpeeksi ja ajallisesti lähellä. On helppo tehdä muutaman rivin muutoksia yksinkertaisiin ominaisuuksiin. Sen sijaan ei ole helppoa tehdä isompia muutoksia saati pystyä johdonmukaisesti muuttamaan isompia kokonaisuuksia, mikäli ei tunne vanhaa toteutusta.

Ihmettelen myös sitä, että jaetussa lähdekoodin omistajuudessa ei kukaan tunnu tietävän keneltä voisi kysyä, mikäli joku asia ei toimi. Joskus vastaus tähän ongelmaan on se, että koska kaikki on kaikkien muokattavissa, niin voit korjata ongelman itse. Tämähän toimii mainiosti, mikäli ongelman hoksaa ajoympäristöjen ylläpitäjä, testaaja tai loppukäyttäjä - eikö vain? Mitä isompi ryhmä vastaa tuotteen toteutuksesta, sen vaikeampi on löytää ihmistä keneltä voi kysyä. Yleensä tekijätkään eivät hetken päästä muista mitä kaikkea ovat toteuttaneet ja minne, koska yksityiskohdat tuppaavat unohtumaan. Vastaava ongelma kohdattaisin nopeasti, mikäli eri tuoteomistajat tai projektipäälliköt joutuisivat vastailemaan erikseen samoihin kysymyksiin: vastaukset olisivat 100% varmuudella erilaisia.

Minun mielestäni on hyvä, että ihmiset tietävät noin suunnilleen mistä palikoista he ovat vastuussa. Tämä tarkoittaa myös sitä, että he muokkaavat tiettyjä lähdekoodin osia pääosin itse ja vastaavat muidenkin tekemistä muutoksista vastuullaan oleviin osiin. Kaikki saavat muokata kaikkea, mutta kaikille osille pitää löytyä selkeät vastuulliset. Eri vastuualueiden välistä raja-aitaa voi helposti pienentää koodikatselmoinneilla ja vastuuttamalla nimettyjä ihmisiä toistensa varahenkilöiksi lomien ja muiden poissaolojen ajaksi. Näin ainakin pari ihmistä kyttää jokaiselle alueelle tapahtuvia muutoksia.

Varsinkin hyvin suuren lähdekoodimäärän ylläpitämisessä ei ole mitään järkeä lähteä hajottamaan kaikkien tekemisiä kaikkialle, koska tällöin varmistetaan se, että oikeastaan kukaan ei kunnolla tunne mitään osaa järjestelmästä. Samalla muutokset rapauttavat järjestelmää kokonaisuutena, koska kukaan kehittäjistä ei välttämättä ymmärrä tai välitä kokonaisuudesta. Voidaan toki väittää, että kaikkien häärääminen kaikkialla pelkästään vahvistaa kokonaiskuvaa järjestelmästä. Isommissa järjestelmissä osaamista pitäisi kuitenkin yleensä olla tähtitieteellisen paljon, jotta ylläpitäjänä voi nopeasti hahmottaa sekä kokonaisuuden toiminnan että kaikki yksityiskohdat.

Projekteissa on usein mukana henkilöitä (useimmiten pitkään projektissa työskennelleet tai muuten vaan keskimääräistä pätevämmät kaverit), jotka pystyvät hallitsemaan erittäin laajoja kokonaisuuksia. Näille poikkeusihmisille ei tuota mitään ongelmia muuttaa koko lähdekoodimassaa koherentisti ja heille ei ole välttämätöntä rajata omaa hiekkalaatikkoa. Toisaalta, vaikka ko. ihmisille annetaan koko projektin lähdekoodiin vaikuttavia tehtäviä, pitää heidän silti muistaa myös keskustella muutoksista eri alueiden vastuullisten kanssa.

Jos tuoteomistajana tai projektipäällikkönä luet tätä tekstiä, niin mietihän seuraavan kerran kahdesti, kun joku tulee vouhottamaan jaetun lähdekoodin autuudesta. Vasta kun olet valmis antamaan tuotteesi tai projektisi muiden satunnaisesti johtamaksi, voit kirkkain silmin todeta jaetun lähdekoodin omistajuuden olevan absoluuttisesti hyvä asia.