A Balancing Act: What Software Practitioners Have to Say about Technical Debt

074 0 -74 5 9 /12 / $ 31. 0 0 © 2 012 I E E E In 1992, Ward Cunningham first described technical debt as writing immature or “not quite right” code in order to ship a new product to market faster.1 Since then, others have refined and broadened the definition to focus on the tradeoffs between expedient short-term decisions and the resulting, potentially crippling, long-term costs.2–5 Some definitions are artifact-centric (that is, something—not necessarily code— must be fixed); others are more taskoriented (that is, something wasn’t done). Moreover, technical debt has been classified by • type (for example, design, testing, or documentation debt), • intentionality, • time horizon (short or long term), and • degree of focus and strategy.