-2000 Lines of Code (2007)

Original Article ↗ Hacker News Discussion ↗

LOC as a KPI and Goodhart’s Law

  • Widespread agreement that using lines of code (LOC/KLoC) as a performance metric is harmful: it rewards verbosity, duplication, and complexity.
  • This is framed as a textbook case of Goodhart’s Law: as soon as LOC becomes a target, developers optimize for more code, not better code.
  • Several note LOC is misleading even when not a formal KPI; it still shapes incentives if managers implicitly value “more code”.

What LOC Actually Indicates (If Anything)

  • Some argue LOC and commit volume can be one weak signal among many: extremely low, trivial-looking commits over months may flag that someone is stuck or underperforming.
  • Others counter that every meaningful case (hard bug, architectural work, mentoring, avoiding unnecessary features) breaks that correlation, so LOC adds no unique value beyond directly reviewing work and outcomes.
  • ΔSLOC (added + removed) is suggested as a slightly better proxy for “change,” but still poor for “productivity.”

Negative LOC and Code as Liability

  • Many celebrate deleting large amounts of code or replacing thousands of lines with small, clear functions as high-value work.
  • Code is repeatedly described as a cost or liability; the asset is the functionality. The best code is often the code not written.
  • Several anecdotes: huge duplicated blocks collapsed into small reusable functions; large snapshot tests or boilerplate removed; long-standing bugs fixed by tiny changes.

Management, Process, and Culture

  • Strong critique of management that leans on easy, shallow metrics (LOC, “impact launches”) instead of understanding the work.
  • Good management is described as: technically competent, reading code, helping with blockers, protecting engineers, and viewing productivity multi-dimensionally.
  • Daily standups are debated: some find them useful for coordination; others see them as “cargo-cult” status rituals that should be replaced by better collaboration and code review.

Power, Unions, and Artisanal Software

  • The story highlights that only high-status individuals can openly ignore bad metrics; others risk punishment.
  • Unions are proposed as protection against retaliatory use of performance metrics, though union downsides and politics are acknowledged.
  • Some lament that large corporate environments have squeezed out “artisanal” software craft, while others note it still thrives in open source and small startups.

AI and Code Volume

  • Participants link the LOC discussion to AI code generation: tools that cheaply produce massive quantities of mediocre code may worsen the “more code = more value” fallacy rather than fix it.