# Do Not Let Technical Debt Get Out of Control

DevFeed: [Do Not Let Technical Debt Get Out of Control](<https://devfeed.tech/articles/do-not-let-technical-debt-get-out-of-control-24937.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/04/27/do-not-let-technical-debt-get-out-of-control/>)

Author: umer

Published: 2016-04-27T00:00:00Z

Content type: opinion

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [business](<https://devfeed.tech/tags/business.md>), [development](<https://devfeed.tech/tags/development.md>), [software](<https://devfeed.tech/tags/software.md>), [teams](<https://devfeed.tech/tags/teams.md>), [technical](<https://devfeed.tech/tags/technical.md>)

## AI overview

The article explains technical debt as the future cost created by quick, dirty design choices. It argues that taking on technical debt can be strategic when immediate feature value is greater, but that teams must understand the risks and repay the debt before it becomes a burden on development, operations, team culture, and morale.

## Source excerpt

Technical debt is a useful metaphor for describing the consequences of adding new functionality to a system in a quick and dirty manner to get something out of the door faster. The proper way would have resulted in a much cleaner design and implementation, but would also have taken much longer. Martin Fowler calls technical debt a wonderful metaphor: Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. Taking on technical debt should be a strategic decision where all stakeholders must understand the consequences and risks involved. Like most financial debts, it should not be taken recklessly and interest payments must be paid on time to avoid penalties. While technical debt has negative connotations, it is an unavoidable reality for many software projects. In her book on Practical Object-oriented Design in Ruby: An Agile Primer, Sandi Metz wrote: Sometimes the value of having the feature right now is so great that it outweighs any future increase in costs. If lack of a feature will force you out of business today it doesn't matter how much it will cost to deal with the code tomorrow; you must do the best you can in the time you have. At Starscriber, we accrued technical debt from time to time to take advantage of new business opportunities and tried to pay it off as soon as the dust settled. But we didn't always succeed. There were at least two projects where the debt got out of control. Implementing (or hacking, would be a better word) new features was a complex and painful process for everyone involved: developers, testers and operations teams. The change requests didn't stopped coming and we m