Torvalds: koodirivien laskeminen on haitallinen mittari

Linus Torvalds, Linuxin luoja, on ankarasti arvostellut Elon Muskin kerrottuja rekrytointi- ja suorituskykymittareita — erityisesti koodirivien laskemista (LOC, lines of code). Laajassa haastattelussa Linus Tech Tips -kanavalla Torvalds tyrmäsi ajatuksen ei ainoastaan harhaisena vaan suoranaisesti ”epäpätevänä” lähestymistapana. Hänen kommenttinsa käynnistivät laajan keskustelun kehittäjäyhteisöissä siitä, mikä oikeasti mittaa ohjelmistokehitysosaamista, ohjelmiston laatua ja tiimien tuottavuutta.

Miksi koodirivien laskeminen on vaarallinen oikotie

Haastattelun aikana juontaja nosti esiin vanhan ohjelmointimetriikan: kokonaiskoodirivimäärän. Raporttien mukaan Muskin ottaessa Twitterin (nykyinen X) haltuunsa insinöörejä pyydettiin tulostamaan lähdetiedostonsa — ja niiden, joilla oli vähemmän tulostettuja rivejä, kerrottiin olevan irtisanomisen vaarassa. Torvalds ei kaunistellut: hän kutsui rivimäärien käyttämistä insinöörien arvioinnissa puhtaaksi kyvyttömyydeksi ja lisäsi, että kuka tahansa, joka ajattelee niin, on liian tyhmä työskentelemään teknologiayrityksessä.

Tämä terävä arvio osuu tärkeään ongelmaan: määrää ei pidä sekoittaa laatuun. Tuottavuuden mittaaminen sen perusteella, kuinka monta riviä joku kirjoittaa, kannustaa turhaan sanallisuuteen, hauraisiin ratkaisuihin ja tarpeettomaan monimutkaisuuteen. Hyvin suunniteltu ohjelmisto tekee usein enemmän vähemmällä — ja koodin minimalismi voi olla merkki ammattitaidosta, ei laiskuudesta. Lisäksi pelkkä LOC-mittari ei huomioi esimerkiksi testien tai konfiguraation osuutta, ei koodin uudelleenkäytettävyyttä, ei arkkitehtuurisia valintoja eikä turvallisuuteen tai suorituskykyyn vaikuttavia tekijöitä.

Kehittäjien reaktiot: melkein yksimielinen epäusko

Redditissä, Stack Overflow’n keskusteluissa ja monissa muissa kehittäjäfoorumeissa ohjelmoijat tukivat Torvaldsin kantaa laajasti. Kommentit vaihtelivat hilpeydestä raivoon ja niissä korostui sama viesti: LOC on yksinkertaistava ja haitallinen mittari. Eräät kommentoijat toivat esiin, että jopa tietojenkäsittelytieteen peruskurssin ensikurssilainen tietää, ettei rivimäärä kerro osaamisesta. Yhteisö argumentoi, että tällainen käytäntö kannustaa paisuttamaan ratkaisuja, lisää virheiden määrää ja kasvattaa teknistä velkaa — juuri päinvastainen tulos verrattuna siihen, mitä yritykset yleensä tavoittelevat skaalatessaan tuotteita tai vakauttaessaan alustaa.

Kehittäjäkeskusteluissa nousi jatkuvasti esiin myös inhimillinen ja organisatorinen näkökulma: kun työntekijöitä arvioidaan pelkästään numeerisin, helposti manipuloitavin mittarein, syntyy palkitsemisjärjestelmä joka suosii pintapuolista tuottavuutta. Tällainen käytäntö voi johtaa heikentyneeseen tiimityöhön, vähemmän dokumentaatioon, ja heikkoihin refaktorointikäytäntöihin, koska yksilöt pyrkivät näyttämään tulokset nopeasti mitattavissa olevilla luvuilla. Lopputuloksena on usein lyhytnäköinen ”nopean voiton” asenne, joka kasvattaa ylläpidon kustannuksia tulevaisuudessa.

Esimerkkejä, jotka havainnollistavat asiaa

• Yksi selkeä ja tehokas algoritmi, joka on noin 100 riviä, voi ylittää 1 000 rivin paikallisparannuksen, joka toistaa logiikkaa ja piilottaa alkuperäisen tarkoituksen. Tämä korostaa, että selkeys ja tarkoituksenmukainen abstrahio ovat arvokkaampia kuin pelkkä rivien määrä.
• Refaktorointi usein vähentää rivimäärää samanaikaisesti lisäten luettavuutta, ylläpidettävyyttä ja testattavuutta — olisiko tiukka LOC-politiikka rankaissut tällaisia parannuksia? Monissa tapauksissa se olisi. Ilman oikeita laatukriteerejä refaktorointi voidaan tulkita ”tuottavuuden laskuna” kun rivit vähenevät, vaikka koodi muuttuu paremmaksi.
• Automaattinen koodin muotoilu, runsaasti lokitusta tai konfiguraation laajentaminen voi nostaa rivimäärää ilman, että toiminnallisuuteen tulee lisäarvoa. Samaan aikaan kriittiset parannukset, kuten suorituskyvyn optimointi tai turvallisuuspäivitykset, voivat lisätä harvoja rivejä mutta tuoda merkittävää hyötyä.

Kuvittele, että palkitsisit kirjoittajia esseiden pituuden mukaan sen sijaan, että arvioisit argumenttien selkeyttä, logiikkaa ja lähdeviittauksia. Sama virheellinen logiikka pätee, kun ohjelmoijia palkitaan määrän — ei käsityön — perusteella. Lisäksi LOC-mittari ei ota huomioon automaattisesti luokkien ja funktioiden uudelleenkäytettävyyttä, modulaarisuutta tai ylläpitäjien kokemusta koodin jatkokehityksestä. Hyvä ohjelmistoarkkitehtuuri voi tarkoittaa, että tietty toiminnallisuus on toteutettu muutamalla rivillä, mutta se on rakennettu niin, että se on helposti laajennettavissa ja testattavissa.

Mitä yritysten tulisi mitata sen sijaan

Jos koodirivien lukeminen ei ole järkevä mittari, mitä johtajien ja rekrytoijien pitäisi seurata? Laadulliset ja prosessipohjaiset mittarit tarjoavat huomattavasti paremman kuvan ohjelmiston tilasta ja tiimin kyvykkyydestä. Esimerkkejä hyödyllisistä mittareista ovat koodikatselmuksissa annettu palaute, bugien esiintymistiheys ja vakavuus, muutospyyntöjen läpimenoajat (lead time for changes), testikattavuus ja jatkuvan integraation (CI/CD) putken vakaus. Nämä mittarit kertovat sekä yksittäisten työntekijöiden että tiimien suorituskyvystä käytännön, mitattavissa olevan laadun näkökulmasta.

Pehmeämmät tekijät ovat yhtä tärkeitä: kyky tehdä yhteistyötä, arkkitehtuurinen ajattelutapa, kommunikointitaidot ja taito yksinkertaistaa monimutkaisia ongelmia erottaa erinomaiset insinöörit keskinkertaisista. Hyvä kehittäjä ei vain kirjoita koodia nopeasti, vaan osaa myös valita oikeat abstraktiot, kirjoittaa testejä, dokumentoida rajapintoja ja osallistua koodikatselmuksiin rakentavalla tavalla. Näitä ominaisuuksia voidaan mitata esimerkiksi arvioimalla koodikatselmusten laatua, tiimien välisiä riippuvuuksia ja palautesilmukoja sekä seuraamalla tuotannossa syntyvien vikojen määrän trendiä.

Teknisten mittareiden lisäksi organisaation tulisi rakentaa mittaristo, joka suosii pitkän aikavälin ylläpidettävyyttä ja vähentää teknistä velkaa. Tämä voi sisältää staattisen analyysin tulokset, turvallisuusauditointien löydökset, modulaarisuuden asteet ja refaktorointien määrä suhteessa uusien ominaisuuksien kehitykseen. Mittaamalla kerralla syntyvän arvon sijaan järjestelmällisesti esimerkiksi arkkitehtuurin parannuksia ja teknisen velan lyhentämistä, yritys voi ohjata insinöörejä käytäntöihin, jotka tukevat tuotteen kestävyyttä ja asiakastyytyväisyyttä.

Torvaldsin kritiikki on muistutus teknologiajohtajille: valitse mittarit, jotka kannustavat ylläpidettävyyteen ja harkittuun suunnitteluun. Muuten vaarana on palkita käytöstä, joka lisää teknistä velkaa ja heikentää tuotteen vakautta — virhe, jonka hinta voi nousta erittäin korkeaksi nopeasti muuttuvassa digitaalisessa ympäristössä. Parhaat käytännöt yhdistävät kvantitatiiviset ja kvalitatiiviset mittarit ja käyttävät niitä kokonaisvaltaisen kuvan muodostamiseen kehitystiimin ja tuotteen tilasta.