I'm often ask how one measures technical debt. Today was no exception.
>I'm looking at 250,000 lines of code. I told my boss that I thought the code had excessive technical debt. He told me to quantify that. So I googled around and saw a span of opinions from it can't be quantified to buy my tool and voila. What do you think?
One might ask, what percentage of your take home pay goes to servicing your personal debt?
Similarly, you could ask what percentage or your time or your team’s time is spent doing work that can’t be explained to the customer as something that they would be pleased to be paying for?
Of course this view makes unfamiliar code, even beautiful code, appear to have a lot of debt. If a company lets developers go and substitutes new developers then they have manufactured what appears a debt at least until the new developers have raised themselves to appreciate the beauty.
The most common form of debt comes from changing requirements or changing understanding of requirements. One might say, if I knew then what I know now I would have surely written the code differently. There are many techniques to manage this debt. I introduced the term to emphasize these.
YOUTUBE pqeJFYwnkjE Published on Feb 14, 2009.
Finally, I think of technical debt as a strategy, not a condition. In a competitive market one might intentionally take on debt in order to win knowing that they will have to work hard to survive their success. In an IPO it is the developers who stay with the company that carry this burden.