Kirjoitettu

Kieroutunut ammattiego pilaa monta ohjelmistoprojektia

Millainen mielikuva tulee sanasta ohjelmistoammattilainen?

Rekryilmoituksissa ja softafirmojen markkinointimateriaaleissa näkökulma on selkeä: pitää sisäistää vaikeitakin asioita nopeasti, pitää ymmärtää monimutkaisia kokonaisuuksia, pitää ottaa vastuuta, pitää tehdä leanisti tai agilesti asioita pala kerrallaan. Pitää osata tehdä työmääräarvioita tarkasti.

Sitten ihmetellään, että miksi projektit epäonnistuvat niin helposti ja deadlinet paukkuvat.

Teoria: hypettämällä luodaan aivan väärä mielikuva siitä, mitä ohjelmistoammattilaisuus on

Kun arjessa jotain tehdään hätiköiden ja kunnolla siihen paneutumatta, sanotaan että asia on juosten kustu. Softapiireissä tämä on agilea ja liiniä sprinttidevaamista. Mitä enemmän näitä termejä ja käytäntöjä mietin, sitä pervommalta ne tuntuvat.

Sprintti – yleensä kaksiviikkoinen – luo mielikuvan kiireellä tekemisestä. Siis vaikka useat asiat vaatisivat laajuutensa puolesta huomattavasti enemmän aikaa.

Kun uraansa aloittavalle devaajalle hoetaan alusta asti, että pitää osata monimutkaisia asioita, iskostuu päähän mielikuva siitä, että ammattimainen koodi on monimutkaista. Ei, ei ole. Nimenomaan laajojenkin kokonaisuuksia pitäminen yksinkertaisena on todellista ammattitaitoa.

Vaatimus vaikeiden asioiden sisäistämisestä nopeasti taas kielii lähinnä siitä, että tuota yksinkertaisuutta ei ole osattu ylläpitää. Tai että tekeillä olevasta ohjelmistosta ei ole (juuri) minkäänlaista dokumentaatiota. Pahimmillaan kyse on näistä molemmista yhtä aikaa.

Suomalaisista korkeakouluista valmistuu joka vuosi koodareita, joilla olisi pohjimmiltaan täydet valmiudet tehdää upeaa ja arkkitehtuurillisesti kaunista koodia. Mutta kun he raukat oppivat huonoille tavoille todennäköisesti jo ensimmäisessä työpaikassaan.

Mitä isompi firma, sitä sakeampi soppa

Sitä voisi luulla, että keskinkertaiset ohjelmistot olisivat vain pienempien pajojen synti. Mutta omien kokemusteni ja kavereilta kuulemieni juttujen mukaan perseily sen kuin lisääntyy, mitä isompaan firmaan mennään.

En ala näitä tarkemmin erittelemään, sillä Reddittiin on postattu tarina siitä, kuinka vakavista asioita voi pahimmillaan olla kyse. Lisäksi tuo juttu on oikein viihdyttävää luettavaa ja hyvin kerrottu. Jos pitkät tarinat eivät pelota, suosittelen lukemaan sen.

Ratkaisuehdotuksia

Jotta tämä postaus ei menisi pelkäksi saarnaamiseksi, esitän lopuksi pari konkreettista ratkaisuehdotusta vinoutuneen ammattiegon runtelemien työtapojen korjaamiseksi.

1. Arviot uusiksi

Ensinnäkin luovutaan nykymallisista aikatauluarvioista. Ne kun eivät ole mitään muuta kuin arvauksia, jotka saatetaan tehdä hyvinkin puutteellisten lähtötietojen pohjalta.

Ja nyt ei auta se marina, että “mutta kun kyllä ammattilaisen täytyy osata tehdä arvioita”. Tämän postauksen perimmäinen idea on nimenomaan kritisoida ajatusta, että tuolla mantralla ja hyppysellisellä keijupölyä järjettömät menetelmät muuttuisivat järjellisiksi.

Sen sijaan että kysyttäisiin “paljonko menee asian X toteuttamiseen?” otetaankin käyttöön kiinteäjaksoinen aikataulu. Eikä mitään nopeaa parin viikon sprinttiä, ellei sitten kyse ole ihan oikeasti pienistä rupeamista. Mutta pääsääntöisesti työlle kannattaa varata vaikka 4 – 6 viikkoa aikaa.

Tuon työjakson päätteeksi käsissä on oltava jotain toimivaa, jotain sellaista, josta voi tehdä tuotantokelpoisen julkaisun.

Aikataulusta ei jousteta, mutta jos kesken työn näyttää siltä, että kiire tulee, karsitaan ominaisuuksista ja yksityiskohdista. Tässä kannattaa muistaa myös Pareton periaate – 80 % työstä pitäisi sen mukaan valmistua 20 % käytössä olevasta ajasta.

Kun työn jaksottaa oikein, ei pitäisi olla mikään ongelma saada aikaan toimivia ominaisuuksia määräajassa. Jos aikaa jää yli, sen voi käyttää viimeistelyyn ja muuhun yksityiskohtaisempaan hiomiseen.

Toisin kuin perinteisessä aikatauluarviomallissa, tällä tavalla saavutetaan enemmän tai vähemmän valmis ja käyttökelpoinen lopputulos jo verraten varhaisessa vaiheessa.

2. K.I.S.S.

Kaikki tietävät tämän lyhenteen, mutta vain harva osaa ja ymmärtää noudattaa sitä.

Keep it simple stupid, yksinkertaisuuden periaate. Sekä koodissa että ohjelmiston arkkitehtuurissa pitäisi pyrkiä kohti yksinkertaisinta mahdollista lopputulosta.

Tämähän ei muuten ole mitenkään softaspesifinen asia. Sama periaate nimittäin tulee esiin esimerkiksi Occamin partaveitsessä ja Einsteinin hiomakivessä. Yksinkertaisuuden etu on siis tiedetty jo vuosisatoja.

Koodausnäkökulmasta suosittelen lukemaan Steve McConnellin kirjan Code Complete. Se oli itselleni aikoinaan silmät avaava teos. Kirja on alunperin vuodelta 1993 ja toinen painos vuodelta 2004. Teoksen oleellisin anti on kuitenkin ajatonta, joten on samantekevää, kumman version käsiisi saat.