|This is the talk page for discussing improvements to the Technical debt article.|
|WikiProject Computing||(Rated C-class, Mid-importance)|
Value judgment phrase
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...
Technical debt is not the same as design debt. Technical debt is the general concept and can apply to low-level coding issues. — Preceding unsigned comment added by 18.104.22.168 (talk) 08:31, 17 March 2013 (UTC)
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 (talk • contribs) 23:24, 29 January 2010 (UTC)
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 22.214.171.124 (talk) 11:54, 25 May 2010 (UTC)
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. — Preceding unsigned comment added by 126.96.36.199 (talk) 16:04, 25 October 2012 (UTC)
Paying off technical debt
Very interesting and increasingly important topic. Could be helpful to clarify what is meant by:
"'Interest payments' are both in the necessary local maintenance and the absence of maintenance by other users of the project.
Not all Technical Debt is the result of poor design
I think the article is very misleading in too narrowly scoping technical debt to things that are the result of poor design. Not all technical debt is "work that needs to be done before a particular job can be considered complete or proper". The article itself eludes to this: '"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project.' So technical debt can apply to any system that requires maintenance of any kind.
All systems have technical debt, even those that are perfectly designed. There will always be maintenance involved, either at the hardware or software level, and if you fail to acknowledge that, then you fail to realize how different architectures minimize long term technical debt.
Technical debt generally also includes the cost of maintaining and supporting an instance of a system. The software could be complete and properly designed, but regardless, you still have technical debt. If the system is designed such that a new instance of the application is needed for each client, then your technical debt is multiplied by the number of customer instances you have to standup.
Often SaaS approach tries to minimize that kind of technical debt by using a centralized multi-tenant system so that long term maintenance/support does not grow significantly in relation to the number of users/customers. This is also the reason(not always justifiable) that many business are moving to the cloud, to decrease the technical debt of maintaining hardware and operating system locally, so that they only need to maintain the instance of the application they are running on the cloud system.