Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 01, 2015, 07:33:46 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Technical Debt - Nice Programming Metaphor and Long Blog Essay  (Read 4122 times)


  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 35,461
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Donate to Member
Technical Debt - Nice Programming Metaphor and Long Blog Essay
« on: November 04, 2007, 06:32:45 AM »
A nice way to look at the cost of cutting corners and making strategic decisions about putting things off..

The term "technical debt" was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.
What is Technical Debt? Two Basic Kinds
The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)


  • Charter Honorary Member
  • Joined in 2005
  • ***
  • default avatar
  • Posts: 1,321
    • View Profile
    • Donate to Member
Re: Technical Debt - Nice Programming Metaphor and Long Blog Essay
« Reply #1 on: January 17, 2008, 07:49:18 AM »
This will become more useful to me in the future, when my coding work increases. I'll keep this in mind...