Jump to content

Talk:Technical debt

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 151.193.120.17 (talk) at 16:04, 25 October 2012 (evolutionary view of the topic). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

The phrase "the architecture of a large software system is designed and developed too hastily" makes a (possibly unwarranted) value judgement about software management practices. Although I am in favor of clean code and good documentation (etc), I also recognize that there may be situations where they can and should be set aside (temporarily) for the purpose of releasing code. This is not inconsistent with the notion of debt; sometimes taking on debt is appropriate...

I think the article should mentioned the keyword 'refactoring'. In some good words, mention that 'refactoring' is a usual outcome of technical debt (in software development). —Preceding unsigned comment added by Evoluzion (talkcontribs) 23:24, 29 January 2010 (UTC)[reply]


Wow, this is an awesome concept, I'm going to start using it more often in the analysis and budgets of the systems i work with :) —Preceding unsigned comment added by 124.169.201.55 (talk) 11:54, 25 May 2010 (UTC)[reply]


Technical debt is code, systems setup, etc what evolution wants to kill, but the debt refuses to die because of people want to keep it living that way.