4 ms·
Discussion of technical debt always seems to devolve into an augment about what technical debt actually is. Are there specific patterns of code behavior, metri
by kgilpin 6y ago
Discussion of technical debt always seems to devolve into an augment about what technical debt actually is.
Are there specific patterns of code behavior, metrics which can be derived from analyzing code, quality scores that are non-controversial, which can be used to define this problem? Things that can be measured and managed in a canonical way? How can some knowledge of experienced CTOs be distilled so that we can start to automate some of this wisdom?
- bananaface 6y agoI would say: technical debt is anything that makes the system more expensive to maintain (and grow) over time, and becomes more expensive to fix the longer you leave it. If it's just a bad or incomplete aspect of the system, that's not sufficient. It has to become more expensive over time. So e.g. lack of functionality isn't tech debt, but a bad abstraction is usually tech debt.