Technical debt
Technical debt is the hidden expense of having to redo work that might have been avoided by opting for a more time-consuming, high-quality solution in the first place.
Technical debt may accrue “interest” and make improvements more difficult to execute in the same way that financial debt accumulates interest.
The entropy of software and the expense of subsequent rework rise when technical debt is not addressed.
Technical debt, like monetary debt, isn't always a terrible thing, and it's sometimes necessary to propel initiatives ahead.
There are also some experts who argue that the “technical debt” metaphor minimizes the consequences, resulting in inadequate prioritizing of the corrective effort
Methaphor - concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer
- CodeScene
- SQALE
- CLOC
- Capability Maturity Model Integration
- Squore
- Attributes
- Quality
- How-tos
- TIOBE Quality score
- Snippet from Wikipedia: Technical debt
Technical debt (also known as design debt or code debt) is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development. While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved. The term is often used in the context of information technology and especially software development.
Technical debt is similar to yet differs significantly from monetary debt. Incurring either generally makes future goals more challenging to attain. But unlike monetary debt, technical debt is often incurred without intention. The choice to minimize development time and cost, an ever-present aspect of business, is the primary factor. Technical debt is generally only assessed retroactively (after a development effort).
Properly managing technical debt is essential for maintaining software quality and long-term sustainability. In some cases, taking on technical debt is a strategic choice to meet immediate goals, such as delivering a proof of concept or a quick release. However, failure to prioritize and address the debt can result in reduced maintainability, increased development costs, and risk to production systems.
Technical debt results from design and implementation decisions that may optimize for the short term, but at the expense of future adaptability and maintainability. System aspects that incur technical debt can be described as a collection of design or implementation constructs that make future changes more costly or impossible, primarily impacting internal system qualities such as maintainability and evolvability.