Hyvä tiimi

Kooderien tuottavuuserot ovat valtavia. Hyvä kooderi käyttää tehtävään viidesosan siitä ajasta joka keskiverrolta kuluu, ja lopputulos on silti monin tavoin parempi. Sama pätee moniin muihinkin ohjelmistotuotannon osiin: arkkitehtuurisuunnitteluun, käyttökokemussuunnitteluun ja myös laadunvarmistukseen. Tämä erottaa kaikki nämä ammatit vaikkapa heinän niittämisestä tai T-fordien kokoamisesta liukuhihnalla.

Ohjelmistojen tekeminen on lähes aina tiimityötä. Tyypillisesti ohjelmistokehitystä tehdään 3-10 hengen tiimeissä (*), joissa on yksi projektipäällikkö tai vastaava, osa jäsenistä on spesialisteja, esimerkiksi testaajia, käyttökokemussuunnittelijoita tai arkkitehtejä, ja loput tekevät koodia. Spesialistit saattaa olla hallinnollisesti eroteltu muista, mutta projekti tuo heidät yleensä silti samaan tiimiin kooderien kanssa.

Oikeastaan pitäisikin siis puhua kehitystiimien eroista. Hyvä tiimi tuottaa paremmin tarkoitukseen sopivan ja luotettavammin toimivan ohjelman nopeammin kuin keskiverto tiimi.

Mikä sitten tekee tiimistä hyvän? Sekö, että se koostuu hyvistä tyypeistä?

Ei välttämättä, eikä ainakaan yksinomaan.

Ihan yksilöiden taitotasosta riippumatta, hyvän tiimin pitää toimia yhteen. Se myös tarvitsee kelvolliset tilat ja hyvät työkalut. Joel Spolsky tiivistää tarvittavat työkalut ja työ-olot 12 kohdan check-listiinsä. Ainakin tämän verran ympäristöllä on väliä.

Parikin astetta pidemmälle ajatuksen vie Alan G. Carter luentosarjassaan Programmers’ stone. Jos lukee hyväntahtoisesti ja ohittaa pseudopsykologian suuntaan osoittavat vihjeet (**), Carterin perusidea on, että hyvän tiimin erottaa huonosta se, että jäsenet löytävät oikeanlaisen keskittymisen ja yhteisymmärryksen, ja sitä kautta itse asiassa ymmärtävät mitä ovat tekemässä tavalla, joka on sitä kokemattomalle lähes käsittämätön.

Tälläisen ”Kullatun tiimin” luomiseen tarvitaan tietysti Joelinkin käisttelemät järkevät tavoitteet, hyvät työkalut, rauhalliset työtilat, tiimin pysyvyys, jne, mutta ennen kaikkea mahdollisuus ylläpitää riittävän matalaa stressitasoa.

Carterin mukaan lähes kuka tahansa ohjelmoija voisi olla kymmenen kertaa normaalia tuottavampi, mutta tätä harvoin tapahtuu, koska normaalissa softafirmassa ei ole yksinkertaisesti mahdollista ylläpitää matalaa stressitasoa. Ainakaan kokonaisen tiimin. Lukekaa koko tarina jos haluatte kattavan selityksen.

Itse uskon, että Carter on oikeilla jäljillä, vaikka välillä menee penkan puolelle. Kaikista tuskin voi ikinä tulla super-ohjelmoijia, mutta hyvä ohjelmointikyky ei ole geneettinen ominaisuus, vaan jotakin, mitä voi oppia. Ei helposti, vaan vaikeasti. Eikä yksikseen, vaan oikeassa seurassa.

(*) Vapaissa ohjelmistoissa työn organisointi toimii aivan eri tavalla, enkä puhu siitä tässä.

(**) Myöhemmin Carter on laajentanut repertuaariaan vähän joka suuntaan jonkinlaiseksi teknohippi-suurmestariksi.

Onnelliset ohjelmistot

Mma Ramotswe-dekkarissa Mma:n kihlattu, automekaanikko ja ehkä Botswanan paras mies J.L.B Matekoni toteaa ”Vain ihminen joka todella ymmärsi koneita, pystyi ajattelemaan moottorin onnellisuutta; sellaista näkemystä mekaanisesti lahjattomilla ei yksinkertaisesti ollut.

Ymmärrän idean moottorin onnellisuudesta, mutta entä mikä tekee softan onnelliseksi? Ehkä softa on moottoria pari astetta abstraktimpana vaikeampi ymmärtää; ehkä siitä on liian kauan kun olen koodannut mitään kunnollista. Tai sitten en vaan ole ollenkaan riittävän lahjakas mekaanisesti (erinomaisen nerokas tapa määritellä teknisluonteinen lahjakkuus empatiana).

Oli miten oli, kysymys softan onnellisuudesta ei ole minulle itsestäänselvä. Niin kuin sen ehkä pitäisi olla. Olen saattanut tehdä urallani suurestakin joukosta ohjelmistoja onnettomia ihan vain ymmärtämättömyyttäni!

Vähän pinnistelemällä keksin muutaman ajatuksen:
* Bugittomuus (tai siis vähäbugisuus) tekee softan onnelliseksi. Kukapa nyt haluaisi kantaa ötököitä sisuksissaan.
* Riittävä välimuisti jossa voi rennosti lepuuttaa sivujaan kutsujen välillä. Ehkä myös nopea prosessori, ettei tarvitse hikoilla suorituksessa liian kauaa vaan pääsee takaisin idlaamaan (tästä kiitos Teemulle, joka ei ikinä kommentoi tänne).
* Kaunis ja siisti arkkitehtuuri. Jos softan arkkitehtuuri on silkkaa spagettia, juuttuu syöte johonkin suolen mutkaan, eikä etene siististi tulosteeksi. Ikävältähän semmoinen tuntuu ja aiheuttaa kaikenlaista ummetusta ja tuskaista räpiköintiä.

Löytyykö lukijoiden joukosta teknisesti lahjakkaita? Mikä tekee ohjelmiston onnelliseksi?