[[Technical debt]], a concept introduced by [[Cunningham, Ward|Ward Cunningham]], refers to the long-term consequences of prioritizing [[Quick and dirty]] solutions over well-designed ones in [[Software development]]. While often seen negatively due to potential future issues and increased maintenance costs, it can be a strategic choice to achieve immediate business needs. Effectively managing technical debt means knowing when to incur it, understanding its trade-offs, and having a plan to minimize its impact over time. [[Software is about driving business, not just technology]]. Many developers mistakenly equate technical debt with poor craftmanship, but taking it on isn't a problem if there's little to no risk of repayment. [[The problem with quick and dirty is the accumulation of dirt]]. **When the lifespan of the software is uncertain, it may be wise to use technical debt to reduce the cost of exploration.** By cutting corners in areas like architecture, testing, or code quality, technical debt allows teams to deliver faster. Leveraging technical debt to shorten [[Time to market (TTM)]] or give the business more time to find the [[Product-market fit]] may be the default way to go. However, [[The problem with quick and dirty is optionality loss]]. ![[The problem with quick and dirty is optionality loss#^40d21f]]