Been chewing on the idea suggested by @nycplayer last night that messy code is not technical debt...it's just the interest.
— Sarah Mei (@sarahmei) November 19, 2015
That's an interesting way to think about technical debt. The amount of interest on a debt is controlled by the interest rate, and also compounding frequency. Higher rate leads to more interest accumulating over time, and so does higher compounding frequency. Compounding frequency for the technical debt interest rate is determined by amount of work that still needs to be done on the code.
For any level of technical debt, i.e. code mess, the cost of technical debt could potentially be nothing - if that code never gets touched again.
However, if the codebase is for a useful, living product, chances are it is continuously going through the transformation. Features are being added and removed, bugs are being worked out or at least mitigated, and structure gets updated. That raises the cost of the technical debt in that codebase tremendously, since the interest is being compounded all the time.
When starting to work on reducing the technical debt in a large codebase, the starting point makes a difference. Starting with the code that changes frequently is a high risk/high return approach: improving technical quality will make a noticeable difference in the technical debt burden. However, it is risky to introduce changes to the code that is exercised a lot and in ways that change frequently.
Alternatively, one can choose to start with less-frequently touched portions of the codebase, to build experience and understanding. The technical debt reduction benefits will be less significant, but the code changes will also be less risky.
No comments:
Post a Comment