Technology Debt
If I hat to pick the one term that causes confusion in code companies, it would be “technology debt.” This metaphor, was coined at least three years ago: “Technology debt is basically when you ‘borrow’ time to avoid having to pay it now – but likely having to pay it later, generally with interest.” (Dharmesh Shah) [Development Short-Cuts Are Not Free] Compared to financial debt, technology debt is less tangible. Some don’t even think the metaphor to be very strong: “unlike real debt there is no external requirement to pay this back.” (Kendall Miller) [Technology Debt?] However I think that Kendall, as many others, is confused. This confusion might be due to the ingrained misconceptions that code mainly has functional-properties, and that each functional-property is implemented as a monolithic block of code. First and foremost, technology debt is mainly about the nonfunctional-properties, like re-usability, maintainability, robustness, security, user-friendliness, (source) controllability, compatibility, extendability, copy-n-past-level, correctness, and so on and on and on. If—as Kendall Miller seems to—one assumes code has mainly functional properties, technological debt translates into limited functionality. Functionality is like taste, “you don’t have to lay an egg to know if it tastes good.” (Pauline Kael) But if you don’t care what the kitchen looks like after making omelets, I want to be your maid nor cook. 
So two functionally-similar blocks of code have a similar technology deficit, so clearly one should pick the cheapest. This assumption gets you a techy techie, because, most every time a techie brings up non-functional technology debt, in what ever form, they are perceived as non-supportive, inflexible, uncommitted or worse. Understanding technology debt is difficult, but important. Misunderstanding it, can be catastrophic.
I think you fundamentally missed Kendall’s point. If you take his quote in context, it includes this:
“It might be that you’ll have to make good on something you deferred, but you might not. If you didn’t, it never was debt. How confident are you that you can tell the difference right now?”
Kendall wasn’t denying the validity of technology debt (especially with regard to non-functional requirements like maintainability). Rather, he was saying that you also need to consider the YAGNI principle as part of a mature decision-making process.
http://en.wikipedia.org/wiki/You_ain't_gonna_need_it
Hi Jay, Are you that Jay that started Gibraltar Software with Kendall? You are right that he does not totally dismiss the notion of technology debt, and he sure made the YPAGNI argument. But I hope I did not offend him (or you) by quoting him out of context. I was trying to point out that some people seem to think the notion is a weak metaphor. At least the example he was giving was about functional properties. The part you are quoting does not swing either way. So at least it was not totally apparent to me that he explicitly included the non-functional properties. I do agree with most of his arguments, but I missed the—in my view, important—distinction between functional and non-functional properties of code.
Hi Coder,
Yes, Kendall is my business partner as well as a good friend for over ten years. We both completely agree that the non-functional aspects of code are a crucial part of its value. In fact, if you take a look at the website for our consulting work, you’ll see that concern for availability, usability and sustainability are central to everything we do.
http://www.esymmetrix.com/approach.aspx
Cheers,
Jay
“the non-functional aspects of code are a crucial part of its value” I like they way you put it, nice and concise. Like something a manager could fit in his attention span and understand. Or at least it gives you a chance to explain “non-functional” to them. 🙂 Cheers!