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.