Technical debt is an explicit choice to optimise for speed of delivery at the cost of having to do more work later to bring the delivered code up to the usual e

Technical debt is an explicit choice to optimise for speed of delivery at the cost of having to do more work later to bring the delivered code up to the usual expectations of code/features in the system. Ideally the choice to take on that technical debt comes with an agreement of when the debt will be paid down and an understanding of the additional work that will be required because of the shortcut being taken now. It is not technical debt if there is no explicit decision, or it is the gradual and continuous bitrot that all codebases suffer. I usually refer to this as cruft and while good design and writing code to optimise for readability / understandability reduce the rate that cruft accumulates, it cannot be stopped due to the nature of software. The best practice I have found to fight cruft is many small refactorings and cleanups as part of every piece of work I deliver. This strategy is outlined in https://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/ https://ronjeffries.com/xprog/articles/refactoring-not-on-th....