-2000 Lines of Code (2007)

Original Article ↗ Hacker News Discussion ↗

Tales from early Apple—where Bill Atkinson was once penalized for deleting 2,000 lines of code while massively improving the Mac’s graphics system—anchor a broader critique of using lines of code as a productivity metric. Commenters argue that SLOC-based KPIs create perverse incentives, ignore high‑value work like debugging, design and saying “no” to features, and conflate code quantity with business impact. Alternative views suggest that code volume and commit history can be one weak signal among many, but only when interpreted by technically strong managers who focus on outcomes and code quality rather than raw counts.

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.