6 Minuter
Linus Torvalds, skaparen av Linux, har öppet kritiserat en anställnings- och prestationsmetrik som enligt uppgift använts av Elon Musk – att räkna kodrader. I en långtgående intervju på Linus Tech Tips YouTube-kanal avfärdade Torvalds idén som inte bara missriktad utan rentav 'ren inkompetens'. Uttalandet väckte snabbt ny debatt i utvecklarkretsar om vad som egentligen mäter skicklighet och produktivitet inom mjukvaruutveckling. Diskussionen rör centrala frågor om kodkvalitet, programvaruutveckling, teknisk skuld och vilka produktivitetsmätningar som ger verklig insikt i hur ett team levererar värde.
Varför att räkna rader kod är en farlig genväg
I intervjun nämnde värden en gammal programmeringsmetrik: totalt antal rader kod. Rapporteringar har antytt att efter Elon Musks övertagande av Twitter, som numera ofta kallas X, bad man ingenjörer att skriva ut sina källfiler och att de med färre utskrivna rader riskerade att sägas upp. Torvalds var kortfattad och tydlig i sin kritik: han kallade användningen av kodrader för utvärdering av ingenjörer för 'ren inkompetens' och påpekade att den som tänker så inte borde arbeta på ett teknikföretag. Denna starka formulering fångade uppmärksamheten eftersom den lyfter fram en viktig princip inom kodkvalitet och produktivitet: mängd är inte samma sak som kvalitet.
Problemet med att räkna rader kod är att det skapar incitament som leder bort från hållbar programvaruutveckling. När belöningen kopplas till volym ökar risken för onödigt långa implementationer, upprepningar, dålig arkitektur och komplicerad logik som är svår att testa och underhålla. Verkligt välskriven kod gör ofta mer med färre rader; det kan röra sig om användning av lämpliga abstraktioner, återanvändbara komponenter, effektiva algoritmer eller kortfattade uttryckssätt. Att straffa kortare, renare implementationer genom att premierar storlek snarare än elegans leder till ökad teknisk skuld, fler buggar och sämre prestanda i längden.
Utvecklare reagerar: en närmast allmän ögonrullning
I forum som Reddit, Hacker News, Stack Overflow-trådar och andra utvecklarnätverk möttes Torvalds kommentar av stöd från många håll. Kommentarerna skiftade från roade till upprörda, och flera påpekade att även en grundstudent i datavetenskap snabbt lär sig att antalet kodrader är en värdelös indikator på produktivitet eller kvalitet. Utvecklargemenskapen framhåller att en strikt regel kring kodrader skapar felaktiga drivkrafter: folk börjar skriva onödiga rader, duplicera logik och undvika refaktorering som skulle göra koden renare och lättare att förstå.
Exempel som illustrerar poängen
- En väl utformad och koncis algoritm på 100 rader kan överträffa en 1000-raders patch som reproducerar logik, döljer avsikten och gör framtida ändringar riskfyllda. I praktiska termer betyder detta att effektivitet, läsbarhet och korrekthet ofta överträffar volym när det gäller underhållbara kodbaser och systemarkitektur.
- Refaktorering reducerar ofta antalet rader samtidigt som kodens tydlighet, moduläritet och testbarhet förbättras. En strikt LOC-policy skulle därmed straffa förbättringar som ökar hållbarheten i kodbasen, eftersom den belönar kodvolym över design och långsiktig hållbarhet.
- Automatisk formatering, konventioner för loggning eller genererade filer kan artificiellt blåsa upp antalet kodrader utan att tillföra funktionalitet eller kvalitet. Att räkna dessa rader ger en missvisande bild av både en utvecklares insats och kodens tekniska hälsa.
Föreställ dig att belöna författare utifrån hur långa deras uppsatser är snarare än hur tydliga och välargumenterade de är. Samma felaktiga logik gäller när utvecklare belönas för massa istället för hantverk. För att skapa goda utvecklingsprocesser och leverera robusta produkter krävs metoder som främjar enkelhet, återanvändbarhet och testbarhet istället för ordmängd i koden.
Vad företag bör mäta istället
Om inte kodrader, vad bör då chefer och ledare i teknikföretag följa upp för att få en korrekt bild av produktivitet och kvalitet? Ett mer genomtänkt ramverk kombinerar kvantitativa och kvalitativa mått kopplade till kodkvalitet, leveransförmåga och teamets samarbetsförmåga. Exempel på relevanta tekniska mätvärden är feedback från kodgranskningar, buggfrekvens över tid, medel-tid till återställning efter incidenter, lead time för förändringar, testtäckning samt frekvens och kvalitet på releaser. Dessa indikatorer ger en bättre bild av hur snabbt och tryggt teamet kan leverera funktioner och lösa problem i en produktionsmiljö.
Utöver tekniska mätvärden är mjuka faktorer viktiga för att särskilja erfarna ingenjörer från medelmåttiga. Samarbetsförmåga i kodgranskningar, förmåga att tänka arkitektoniskt, mentorskap, förmåga att förenkla komplexa problem och kompetens i att skriva tydlig dokumentation är kritiska egenskaper. Att premiera dessa beteenden minskar teknisk skuld och underlättar långsiktig skalbarhet i produktutvecklingen. Verktyg som CI/CD-pipelines, statiska analyser, automatiska tester och kontinuerlig övervakning ger dessutom objektiva mått som stödjer kvalitativa bedömningar.
Praktiska rekommendationer för ledare och chefer är att använda en mix av indikatorer, undvika enstaka mått som skapar pervers konkurrens och istället designa mål som främjar hållbar design, återanvändning och snabb feedback. Till exempel kan en KPI som fokuserar på minskning av teknisk skuld över tid, förbättrat genomsnittligt mottagande i kodgranskningar eller ökad testtäckning vara mer meningsfull än att mäta producerade kodrader. Dessutom bör man komplettera mätningarna med regelbundna tekniska omdömen, 1-1-samtal och peer reviews för att fånga upp beteenden som inte syns i råa siffror.
Torvalds kritik påminner tekniska chefer om att välja metoder som uppmuntrar underhållbarhet, testbarhet och genomtänkt design. Felaktigt val av mätmetod kan resultera i att man belönar beteenden som ökar teknisk skuld och undergräver produktstabilitet, vilket i slutändan kostar mer i tid och resurser. Att bygga en datadriven men samtidigt kvalificerad och mänskligt bedömd process för att utvärdera ingenjörer och team är avgörande för långsiktig framgång i mjukvaruutveckling.
Källa: smarti
Kommentarer
Tomas
Sett exakt detta på ett tidigare jobb, cheferna ville boosta LOC så vi skrev onödiga rader för statistiken. Refaktorering blev straffad, buggarna ökade. Mät bättre, inte längre.
kodvåg
Wow Torvalds går rakt på sak och jag nickar, det här är farligt i praktiken. Att mäta rader kod ger bara copy paste, mer teknisk skuld och sämre design. Kortare kod kan vara snyggare och tryggare, punkt.
Lämna en kommentar