4 ms·
Technical debt
- majc2 12y agoTechnical debt isn't drastic enough to get people's attention - in particular management. I prefer to talk about the technical credit card - I find that it gets across the point that the debt needs to be addressed.
- angersock 12y agoI think a better metaphor is sub-prime loans...as long as you can hand the codebase off to the next schmuck while turning a profit, everything's fine, and they do the same, and so on and so forth. One day you lose your home.
- michaelfeathers 12y agoTechnical Debt is a great metaphor, but it is just a metaphor. I've seen people try to quantify it and it just seems ridiculous. They try to take some measure of badness and then multiply it by the number of person hours it takes to correct it. Much of what counts as badness in code never gets in the way until you have to understand or touch a particular area of code. The impact depends upon change cases.
- deleted 12y ago[deleted]
- wpietri 12y agoHi, Michael! I agree it is hard to quantify, but many things are. A good analogy is deferred maintenance [1]. That's where you fail to maintain something like a building or a piece of machinery. There's a new and complicated federal standard for measuring it. [2] Measuring technical debt for software is especially hard, because we don't measure much else about it. Programmers sit around coding, presumably creating a valuable asset. But it's hard to say what the value is, so we mostly don't. That makes it even harder to estimate how bad code reduces the value of that asset. One easy proof that it's more than a fuzzy metaphor, though, is how often people declare technical bankruptcy. There's the total rewrite, our equivalent of Chapter 7. [3] And we have the partial rewrite and the cleanup around a major new version, both akin to Chapter 11. [4] I agree that some of those rewrites are driven by new use cases just being so wildly different than the old ones that it's on longer the same system. But a lot of what I'd call technical debt would have to be cleaned up for most likely changes. One could look at it from an "if we don't change it, the debt never counts" perspective, which makes the debt look as if it isn't real. But I have yet to see a software project that keeps running for an extended period without anybody wanting to change it, so I think that perspective is a false hypothetical. [1] http://en.wikipedia.org/wiki/Deferred_maintenance http://en.wikipedia.org/wiki/Deferred_maintenance [2] http://www.fasab.gov/pdffiles/handbook_sffas_42.pdf http://www.fasab.gov/pdffiles/handbook_sffas_42.pdf [3] http://en.wikipedia.org/wiki/Chapter_7,_Title_11,_United_States_Code http://en.wikipedia.org/wiki/Chapter_7,_Title_11,_United_Sta... [4] http://en.wikipedia.org/wiki/Chapter_11,_Title_11,_United_States_Code http://en.wikipedia.org/wiki/Chapter_11,_Title_11,_United_St...