Niin kauan kuin olen ollut ohjelmistoalalla, on puhuttu 10x-kehittäjästä. Näiden ihmisten haluatte ratkaisevan ongelmanne; he tekevät sen kymmenesosassa ajasta ja kymmenesosalla koodirivien määrästä. He kuulostavat mahtavilta.
Mutta mistä termi on peräisin? Onko niitä olemassa? Ja vaikka niitä olisikin, haluaisitko silti olla sellainen?
Tom DeMarco ja Tim Lister ovat vuodesta 1977 lähtien järjestäneet ”Coding War Games” -kilpailuja. Kyseessä on julkinen tuottavuustutkimus, jossa eri organisaatioiden ohjelmistototeuttajista koostuvat tiimit kilpailevat saadakseen valmiiksi sarjan vertailuarvoja minimaalisessa ajassa ja minimaalisilla virheillä. Tutkimukseen on osallistunut yli 600 kehittäjää.
Mitä he saivat selville?
- Ohjelmointikielen valinnalla ei ollut juurikaan vaikutusta – olipa kyseessä COBOL/Fortran tai Pascalin kaltainen korkean tason kieli, tulosten hajonta oli suunnilleen sama. Ainoa poikkeus oli assemblerikieli.
- Kokemuksen ja suorituskyvyn välillä ei ollut mitään korrelaatiota, paitsi että ne, joilla oli alle kuuden kuukauden kokemus jostakin kielestä, eivät pärjänneet yhtä hyvin kuin muut.
- Nolla virhettä -ratkaisujen kehittäjät eivät maksaneet suorituskykysakkoa siitä, että he tekivät täsmällisempää työtä (itse asiassa heiltä kului hiukan vähemmän aikaa!).
Organisaatioiden välillä havaittiin kuitenkin suuria eroja. Paras organisaatio työskenteli 11,1 kertaa nopeammin kuin huonoin. Lisäksi ne, jotka työskentelivät nopeimmin, kehittivät koodia, joka läpäisi hyväksymistestin. Tapaus on loppuun käsitelty?
No, ei ihan. Tutkimus jatkaa sitten korreloimalla työympäristön (joka on erilainen eri organisaatioissa) ja suorituskyvyn välillä. Kävi ilmi, että hiljainen, yksityinen, oma työtilaryhmä suoriutui merkittävästi paremmin.
Oppi, joka on opittu – laita työympäristösi ensin kuntoon, ennen kuin alat murehtia, löydätkö 10x kehittäjää vai et!
Nettonegatiivisesti tuottava ohjelmoija
Schulmeyer huomauttaa, että jotkut kehittäjät ovat ”nettonegatiivisesti tuottavia ohjelmoijia” (Net Negative Producing Programmer, NNPP), eli he tuottavat niin paljon virheitä, että heidän poistamisensa tiimistä lisää tuottavuutta. Tämä on melkein 10x-kehittäjän vastakohta – tiimissä voi olla joku, joka huonontaa sitä.
Jos negatiivisia tuottajia on olemassa (- Nx-kehittäjiä?), niin silloin on selvästi mahdollista olla 10x kehittäjä (matematiikkaa lukuunottamatta).
Ei kuitenkaan ole kovin hyvä argumentti 10x ohjelmoijan puolesta, eihän? Jos pyytäisin koululaisen mukaan tiimiin, olisiko hän nettonegatiivinen tuottaja? Todennäköisesti, jos antaisin heidän istua nurkassa ja mätkiä koodia (ja jos he jollain tapaa osaisivat puskea tuotantoon!). Jos olet sellainen yritys, joka antaa ihmisten istua nurkassa, ei anna palautetta ja päästää heidät tuotantoon, luultavasti ansaitset NNPP:t tiimissäsi!
Realistisemmin toivon, että missä tahansa normaalissa yrityksessä, jos palkkaat jonkun, annat hänelle kaiken tuen, mitä hän tarvitsee ollakseen mahtava tehtävässään (vertaiskoodin arvostelu, palaute, mentori, automaattinen koodianalyysi palautteen saamiseksi, oppimateriaali jne.)
Voi kai silti olla mahdollista, että päädyt NNPP:hen, mutta epäilen, että se on erittäin epätodennäköistä. Tämä ei ainakaan vaikuta parhaalta tarinalta 10x kehittäjien olemassaololle.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant julkaisivat vuonna 1968 artikkelin ”Exploratory experimental studies comparing online and offline programming performance”. Yksi lopussa olevista lainauksista koskee yksilöllisiä eroja ja tutkimukset ”paljastivat suuria yksilöllisiä eroja korkean ja matalan suorituskyvyn välillä, usein suuruusluokkaa”. Voisiko tämä olla se maaginen paperi, joka kuvaa tuota 10-kertaista eroa?
Maksaa lukea koko tutkimus ja laittaa vähän kontekstia tämän ympärille. Ensinnäkin näissä testeissä verrattiin sekä kynällä ja paperilla että verkossa IBM AN/FSQ-32:lla suoritettua suorituskykyä. Ohjelmoijat kirjoittivat koodinsa (joko kynälle/paperille annettavaksi operaattorille tai suoraan tietokoneelle) käyttäen kieltä nimeltä JTS (ALGOL-johdannainen).
Heillä oli kaksi tehtävää ratkaistavana, joista ensimmäinen oli tulkita algebrallisia yhtälöitä, joissa oli yksi riippuvainen muuttuja. Heille annettiin Samelsonin ja Bauerin paperi, joka auttoi ratkaisun toteuttamisessa. Alla on kuva paperista:
Toisessa tehtävässä oli ratkaistava 20×20-ulotteinen labyrintti, jossa on tasan yksi polku. Sokkelo kuvattiin 400-alkioisella hakutaululla, jossa jokainen merkintä sisälsi tiedon kunkin solun uloskäynneistä. Tätä tehtävää varten ei toimitettu tukimateriaalia. Sokkeloiden ratkaiseminen on kiehtova ongelma-alue, ja arvelisin, että niillä, jotka olivat hiljattain suorittaneet graafiteorian kurssin, oli suuri etu!
Tietäen nämä tehtävät, en ole yllättynyt siitä, että yksilölliset erot ovat suuria. Vuonna 1968 ohjelmistotekniikka oli vasta syntynyt tieteenalana. Tehtävät ovat luonteeltaan matemaattisia, eikä ole selvää, mikä oli osallistujien tausta. Se suosisi varmasti niitä, jotka ovat käyneet korkeamman tason matematiikan kursseja.
Luulen, että tästä löytyisi 10x henkilö, joka on lahjakas ratkaisemaan näitä ongelmia. Voin uskoa, että ongelma-alueella ”labyrintin ratkaiseminen + lineaariset yhtälöt” voi olla 10x kehittäjä, mutta on vaikea uskoa, että tämä siirtyisi mihinkään muuhun alueeseen.
Pitäisikö minun olla 10x kehittäjä?
Todennäköisesti. Mutta luultavasti 10x parempi koodin kirjoittamisessa.
Tässä erinomaisessa kirjassa on paljon parempi keskustelu 10x-kehittäjä-myytin taustalla olevista tutkimusmenetelmistä. Vaikka 10x-kehittäjä olisikin olemassa, sinun ei luultavasti kannattaisi pyrkiä sellaiseksi; vaikka osaisitkin toteuttaa koodin täydellisesti ensimmäisellä kerralla, huomaat luultavasti ratkaisevasi väärän ongelman alunperin.
Vaikka nuo tutkimukset olisivatkin totta, ohjelmistotekniikka on mennyt eteenpäin (ainakin omalla alueellani tuotekehityksessä).
Vanhoina aikoina saatoimme tehdä yhden ison julkaisun vuodessa, meillä oli joitain vaatimuksia, ja käytimme vuoden niiden toteuttamiseen. Tästä on siirrytty ketterään lähestymistapaan, jossa on jatkuva sykli, jossa vaatimuksia kartoitetaan, kuvitellaan, toteutetaan ja tarkistetaan. Tässä mallissa toteutus ei ole (yleensä) pullonkaula
Ei pullonkaulassa säästetty tunti on harhaa. (Eliyahu Goldratt)
Mitä sen sijaan pitäisi tehdä? No, keskity siihen, että olet arvokkaampi yrityksellesi. Pystytkö:
- Tunnistamaan liiketoimintasi kannalta arvokkaat ongelmat?
- Suunnittelemaan ratkaisun, jota ihmiset voivat käyttää?
- Keräämään palautetta arvioidaksesi, onko se arvokas?
- Kirjoittamaan ohjelmiston, jolla on todellista merkitystä todellisille ihmisille?
- Keskity mieluummin todellisiin ongelmiin kuin mielenkiintoisiin?
- Kasvattaa tiimin jäseniä mahtaviksi?
Ja miljoona ja yksi asiaa, jotka ovat arvokkaampia kuin täydellisen koodin kirjoittaminen ennätysajassa (vrt. t-kirjaimen muotoinen!).
Tämä ei tarkoita, etteikö koodaaminen olisi tärkeää. Koodaaminen on tärkeää! Koodia luetaan 4x enemmän kuin sitä kirjoitetaan, joten jos kirjoitat helposti järkeistettävää koodia, niin se maksaa itsensä dramaattisesti takaisin tulevaisuudessa (ehkä jossain on 10x tarina, mutta jätän sen toiselle päivälle). Ajan sijoittaminen omaan ammattitaitoon (oli se sitten koodausta, suunnittelua tai projektinhallintaa) on välttämätöntä, mutta muista, että ammattitaitosi ei ole olemassa irrallaan, vaan se on olemassa palvellakseen korkeampaa päämäärää.
Älä keskity vain siihen, että olet maailman paras kehittäjä, vaan keskity laajempaan kokonaisuuteen (muista Product over Project!). Opettele laaja joukko taitoja (erityisesti ihmisiin liittyviä taitoja) ja olet paljon arvokkaampi ja paljon lähempänä todellista 10x ”kehittäjää”.