All code is technical debt
Framing “all code as technical debt” provokes debate over whether the term has been stretched beyond usefulness or usefully highlights that every added feature and line of code carries ongoing cost. Commenters revisit Ward Cunningham’s original debt metaphor, contrast it with the modern “shortcut” interpretation, and argue that code is better viewed as a liability, inventory, or depreciating asset whose value must justify its maintenance and complexity. Many emphasize that real leverage comes from fewer, well-chosen features, aggressive deletion of unused code, and involving business stakeholders in explicit trade-offs between speed, quality, and long‑term flexibility.
Scope of “Technical Debt”
- Many argue the article dilutes “technical debt” by calling all code debt; they see technical debt as specific shortcuts or misaligned designs that incur “interest” in future work.
- Others broaden it: any mismatch between current code and current understanding/requirements, or more generally, any impediment between what you want to do with the system and how it actually is.
- There is debate over the original meaning (learning-driven design lag) vs the modern “we knowingly cut corners” usage; some regret that precise terms like “technical debt” and “refactoring” have blurred.
Code as Liability, Asset, or Inventory
- Strong theme: code is a liability/carrying cost. More code → more to understand, maintain, and adapt; deleted code is celebrated.
- Counterpoint: runnable software and useful features are assets; code is at least partly an asset because it enables change and value creation.
- Some prefer analogies like “inventory” or “depreciating asset” rather than “debt” or “pure liability.”
Complexity, Features, and Assumptions
- More features and assumptions increase complexity and future friction, even if they “work” today.
- Several note that most projects don’t remove enough code or features; obsolete or unused code persists, accruing hidden costs.
- A recurring idea: good engineering is minimizing assumptions and concepts, and working within existing ones where possible.
Quality, Entropy, and Maintenance
- Many see technical debt as a form of entropy: even well-intentioned decisions accumulate into complexity as requirements, platforms, and people change.
- Distinction made between “bad programming” and good code that simply reflects outdated understanding or requirements.
- Tests and abstractions also carry cost; over-abstraction (e.g., DRY taken too far) can be worse than duplication.
Organizational and Communication Issues
- Business stakeholders often treat “technical debt” as a purely technical nuisance; commenters emphasize framing it in terms of time-to-market, reliability, and opportunity cost.
- Management incentives favor adding features and deferring cleanup; proposing refactors or rewrites is risky and highly blame-attracting.
Reception of the Article
- Some found the headline and premise clickbaity or reductive; others appreciated that it sparks reflection on overbuilding, feature creep, and the value of writing less code.