Kodelinjer er tilbake (og det er verre enn før)

Kodelinjer er tilbake som en produktivitetsmåling, og programvareteam overalt bør være skremt. Det som en gang ble miskreditert som et farlig misvisende mål på ingeniørutdata, har i det stille sneket seg tilbake til styrerom, ytelsesvurderinger og AI-genererte dashboards – og denne gangen er konsekvensene for virksomheten din langt mer alvorlige.

Hvorfor ble kodelinjer noen gang en produktivitetsmåling i utgangspunktet?

Besettelsen med linjer med kode (LOC) går tilbake til 1960- og 1970-tallet, da programvare fortsatt var ny, ledere fortsatt var forvirret, og å telle noe – hva som helst – føltes bedre enn å telle ingenting. Hvis en utvikler skrev flere linjer, gjorde de sikkert mer arbeid, ikke sant?

Logikken var alltid feil. Bill Gates advarte som kjent at å måle programvareproduktivitet ved hjelp av kodelinjer er som å måle flyproduksjon etter vekt. Et fly som er dobbelt så tungt er ikke dobbelt så bra. Det er heller ikke kode som er dobbelt så lang.

På 1990- og begynnelsen av 2000-tallet hadde industrien stort sett gått videre. Smidige metoder, resultatbasert måling og en økende forståelse av teknisk gjeld presset LOC ned i søppelbøtta med dårlige ideer. Ingeniører feiret. Produktsjefer tilpasset. Bedrifter begynte å måle hva som faktisk betydde noe: funksjoner som ble sendt, feil løst, oppnådde brukerresultater.

Hva er det som driver tilbake til linjer med kodebesettelse?

To krefter har konspirert for å gjenopplive denne zombie-metrikken: AI-kodegenereringsverktøy og utøvende press for synlig produktivitetssikkerhet.

Da GitHub Copilot, Cursor og lignende verktøy oversvømmet markedet, forsøkte selskaper å rettferdiggjøre AI-investeringene sine. Den enkleste måten å vise avkastning på? Tell linjene med kode disse verktøyene produserer. Plutselig genererte ingeniørteam tusenvis av linjer per dag - og ledere begynte å behandle dette tallet som en overskriftsprestasjon.

I mellomtiden skapte eksternt arbeid og distribuerte team en ny angst blant ledere som ikke kunne se utviklerne deres fysisk skrive. Etterspørselen etter kvantifiserbare produksjonsmålinger økte. LOC ga en illusjon av synlighet. Det føltes objektivt. Det føltes målbart. Det føltes trygt.

Det er ingen av disse tingene.

Hvorfor er comebacket verre enn det opprinnelige problemet?

Da menneskelige utviklere skrev overdreven kode for å blåse opp LOC-numrene deres, ble skaden begrenset av menneskelig hastighet. En utvikler kan bare skrive så fort, finne opp så mange overflødige funksjoner eller fylle ut så mange kommentarblokker i løpet av en arbeidsdag.

AI endrer alt. En enkelt utvikler med en AI-assistent kan nå generere titusenvis av linjer på timer. Hvis ytelsesgjennomgangen deres belønner volum, har de alle insentiv til å la AI-en løpe løpsk – og produserer omfattende, oppblåst, uopprettholdbar kode som ser imponerende ut i et regneark og er katastrofal i produksjon.

"Den farligste metrikken er en som er enkel å spille. Når belønningen er kodelinjer, er ikke resultatet mer produktivitet – det er mer kode. Det er veldig forskjellige ting."

Nedstrømseffektene er alvorlige og sammensatte. Oppblåste kodebaser er vanskeligere å feilsøke, tregere å distribuere, dyrere å vedlikeholde og langt mer sårbare for sikkerhetsutnyttelser. Hver linje med unødvendig kode er en fremtidig forpliktelse som sitter på balansen din, usynlig til den bryter noe kritisk.

Hva bør moderne virksomheter egentlig måle i stedet?

Den gode nyheten er at bedre alternativer finnes og allerede er kamptestet av høyytende ingeniørorganisasjoner. Hvis bedriften din for øyeblikket sporer LOC i noen kapasitet, erstatte den umiddelbart med beregninger som faktisk korrelerer med forretningsresultater:

Distribusjonsfrekvens: Hvor ofte sender teamet ditt fungerende programvare til produksjon? Høyytende team distribuerer flere ganger per dag, ikke per kvartal.

Ledetid for endringer: Hvor lang tid tar det fra en forpliktet kodeendring til den endringen kjører i produksjon? Kortere er bedre – det betyr at prosessen din er slank og responsiv.

Endre feilfrekvens: Hvor mange prosent av distribusjonene forårsaker incid

Frequently Asked Questions

Are lines of code ever a useful measurement for anything?

LOC has limited use in very specific contexts, such as estimating the rough scope of a legacy codebase for migration planning, or calculating software complexity using derived metrics like cyclomatic complexity. However, it should never be used as a productivity metric or a measure of individual developer performance. In those contexts, it actively incentivizes bad outcomes.

How do AI coding tools change the lines of code problem?

AI coding assistants dramatically accelerate the generation of code, which means the volume problem scales exponentially when LOC is treated as a success metric. Teams using AI tools with LOC-based incentives will produce massive, bloated codebases far faster than pre-AI teams could. The solution is to pair AI tools with outcome-based metrics so the speed of generation is matched by a corresponding focus on quality and usefulness.

What's the fastest way for a business to shift away from vanity metrics?

The fastest path is to consolidate your operational tools onto a platform that tracks outcomes by design rather than bolting reporting onto existing workflow tools. When your business OS connects team activity to business results in real time, the right metrics surface naturally and vanity metrics lose their appeal because better information is always available.

Your business deserves metrics that tell the truth. Stop counting lines of code and start measuring outcomes that actually drive growth. Explore Mewayz at app.mewayz.com and see how 138,000 businesses have built smarter operations — starting at just $19 per month.

Related Posts

• Chrome-utvidelser spionerer på brukernes nettleserdata
• Hvordan fikk Windows 95 tillatelse til å sette Weezer-videoen 'Buddy Holly' på CD-en?
• Databaser bør inneholde sine egne metadata – Bruk SQL overalt
• Tapt sovjetisk månelander kan ha blitt funnet