Technical debt
A metaphor for internal software shortcomings that make later changes harder or riskier.
What is technical debt?
Technical debt uses a debt metaphor to describe how shortcomings or earlier decisions in software’s internal structure make later changes more laborious or risky. It is not an accounting liability. Old code alone does not establish technical debt; concrete effects on needed work matter.
In a fictional example, the same approval rule was copied into several places. A change must now reach every copy and risks producing inconsistent decisions. A backlog entry can record the cause, affected workflows, expected consequences and an accountable role with an improvement proposal. Priorities depend on use, risk and upcoming changes. This does not automatically mean the entire application must be rewritten.
Sources
Related terms
- RefactoringChanging software’s internal structure while preserving its expected observable behaviour.
- Legacy systemAn existing system still in use, with technical and business dependencies accumulated over time.
- Multi-tenancyMulti-tenancy supports separate customer or group scopes in one solution. A tenant is not automatically one person or one database.
- Browser cacheThe browser cache stores suitable HTTP responses for later use. Reuse and revalidation follow the applicable rules.
- Cache invalidationCache invalidation ends reuse of a stored copy under defined rules. The source record remains a separate concern.
- CachingCaching reuses stored data or results. Validity and the permitted user scope belong in the design.
Articles on this topic
Software Development with ASES
Custom software, web and mobile apps