Paras tapa tehdä ohjelmistokehitystä on olla tekemättä sitä

Metodologioiden huumassa unohtuu välillä korkeamman tason ajattelu ohjelmistokehityksestä. Ohjelmiston kirjoittamisen kustannusten (suorien ja epäsuorien) vähentämisen ylivoimaisesti tehokkain tapa on välttää ohjelmiston kirjoittaminen kokonaan.

Otetaan esimerkki: aikanaan Codentossa huomattiin joidenkin työntekijöiden tekevän jatkuvasti ylitöitä. Tätä haluttiin kontrolloida jollakin tavalla, jos ei vähentämällä päivittäisiä tunteja, laittamalla työntekijät kertymän sitä edellyttäessä pitämään vapaapäiviä.

Ohjelmistoyrityksenä Codentolla oli tietty suuri vaara joutua kehittämään oma työajanseurantasovellus, mikä olisi järjetöntä. Oikea tapahan on ostaa valmis sovellus, koska sama ongelma on lähes kaikilla pienyrityksillä, ja hyvä ratkaisu varmasti löytyy markkinoilta.

Vai onko?

Se mitä tosiasiassa tapahtui, oli, että puolen tunnin miettimisen jälkeen toimiston ulko-oven viereen asennettiin whiteboard, joka jaettiin työntekijäkohtaisiin sarakkeisiin sekä kertymä- ja vajausriveihin. Magneettisesta levystä leikattiin numeroita, jotka vastaavat kertymä- ja vajausruuduissa vastaavan tuntimäärän kertymää ja vajausta.

 

Taulu on käytössä tänäkin päivänä. Yhdellä silmäyksellä näkee, että toimitusjohtaja (jota työaikalaki ei koske) on taas tehnyt järkyttävästi ylitöitä. Muilla plussaa ja miinusta on vähän kohtuullisemmissa määrin. Tiistaina tauluun piti piirtää uusi sarake, kun yrityksessä aloitti uusi työntekijä. Vanhoja sarakkeita kavennettiin vähän, että uusi mahtui. Aikaa meni ehkä minuutti, jonka aikana uusi työntekijä perehdytettiin työajanseurantajärjestelmään.

Ohjelmistojen tarvetta kannattaa aina miettiä toisenkin kerran. Se, että joku tarve on joskus tyydytetty ohjelmistolla, ei ole todiste siitä, että se olisi ollut edes silloin järkevä ratkaisu, puhumattakaan siitä, että se olisi sitä nyt.

En muista onko Codento koskaan päässyt suosittelemaan asiakkaalle softan täysin kirjoittamatta jättämistä, mutta ainakin alkuperäisen vision leikkaaminen kymmenesosaansa on tehty. Voittajia olivat luultavasti kaikki, vaikka laskutusta ei tullutkaan yhtä paljon.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Jakaminen versionhallintavarastojen välillä alipuuyhdistyksellä

Ohjelmistokehityksessä on joskus tarve sisällyttää toisen projektin lähdekoodi oman projektin versionhallintaan moduulina tavalla jossa muutokset moduuliin voivat liikkua hallitusti molempiin suuntiin oman ja toisen projektin välillä: omassa projektissa voi tehdä muutoksia toisen projektin lähdekoodiin jotka myöhemmin voidaan hallitusti viedä takaisin alkuperäiseen toiseen projektiin, sekä toisen projektin uusia muutoksia voidaan hallitusti tuoda omaan projektiin.

Tämä onnistuu esimerkiksi Git:in alipuuyhdistysstrategialla (engl. subtree merge strategy). Alla sarja komentoja ajettava oman projektin työhakemistossa jolla saa $subtree_url-osoitteessa olevan projektin $subtree_dir-nimiseen alihakemistoon omassa projektissa:

git remote add -f $subtree_repo $subtree_url
git merge -s ours --no-commit $subtree_repo/master
git read-tree --prefix=$subtree_dir/ -u $subtree_repo/master
git commit -m "Merge $subtree_repo as subdirectory."

Tämän jälkeen alihakemistoa voi muokata vapaasti paikallisten tarpeiden mukaan. Muutokset toisesta projektista saa aina tarvittaessa tuotua alihakemistoon seuraavalla komennolla:

git pull -s subtree $subtree_repo master

Mahdolliset paikalliset muutokset yhdistetään tällöin hallitusti toisen projektin muutoksiin. Paikalliset muutokset voidaan vastaavalla tavalla viedä toiseen projektiin käyttämällä samaa alipuuyhdistysstrategiaa toisen projektin puolella koska alipuuyhdistysstrategia tunnistaa itse kumpi puoli on alipuu.

Hyvä puoli alipuuyhdistysstrategiassa on että se ei vaadi lisätoimia oman projektin versionhallintakäyttäjiltä tuodun moduulin suhteen, koska se on sisällytetty omaan projektiin tasavertaisesti oman koodin kanssa. Vertaa Git:in alimoduuleihin (engl. submodules) joka on toinen tapa tuoda ulkopuolisen projektin omaan projektiin, mutta vaatii lisätoimia versionhallinan käyttäjiltä (alimoduulien alustaminen).

Alipuuyhdistysstrategiasta kiinnostuneille Junio Hamanon selitys Git-postituslistalla on hyvä johdanto aiheeseen.

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.