21 ms·

Well, I did what the author suggested, and wrote down my definition. After a short internal dialog, I came up with this: "Technical debt is the burden that imp

• dr-detroit 5y ago
  a peanut is neither a pea nor a nut I think the author was drawing parallels to this aphorism so their writing would not come off as soulless and mechanical as your writing style.
• mat0 5y ago
  Yup. For instance, he mentions interest rate. Why? How is it useful to think about it and precisely define it in this context? Next article: the cloud isn't even a cloud, it isn't made out of small particles of water!
  • sollewitt 5y ago
    The "interest" is a metaphorical measure of how sustainable your situation is, and how urgently you need to address the "principal". If you incur technical debt as a mismatch between your codebase and your requirements (owing to the evolution of requirements) initially you may just be able to work around the mismatch, but it starts to incur "extra" work - this has been called the "interest" in the extended metaphor. Everything you do that isn't addressing the mismatch keeps adding to the debt though, so eventually the "interest" becomes equal to your entire budget and no more forward progress can be made, and typically bankruptcy is called (give up on code base, propose rewrite to address the actual requirements) and the cycle starts again.
• phkahler 5y ago
  There are two quotes from Cunningham in there: A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. >> Cunningham disliked the notion that technical debt signified “doing a poor job now and a better one later.” This was never his intention. You can split hairs of weather code was poorly written vs written from an underdeveloped understanding of the problem, but the effect is the same. People have to deal with suboptimal design decisions repeatedly until they are corrected. To extend the debt/interest metaphore, these poor decisions also undergo compounding if not paid back.
  • JKCalhoun 5y ago
    I am someone else who apparently never understood what technical debt was supposed to mean. I've always assumed engineers (myself included) write code to the best of their abilities to solve a given problem at the time. But we all know that, over time, features and such get added to the code base and it is stretched beyond what it was originally meant to do. That the code base would should be refactored to better accommodate these new features that have been glommed on is the tech debt. There was nothing poor about the original implementation and the additional features were added with the understanding that the code could not be rewritten from scratch. I may be splitting hairs here but I want to make the distinction that at no point was an engineer making poor choices. I want to point this out not to sound defensive, but rather to make it clear that when I use the term "tech debt" I am not saying it in a castigating or "accusational" way. There is no shame in tech debt. (BTW, other engineers I've worked with, will add a "BOGUS" comment next to any line of code they are in fact embarrassed by with some explanation like "using very small number here, render crashes if border is zero thickness.". Do a search for "BOGUS" in the sources to discover you BOGUS debt.)
    • naasking 5y ago
      > I may be splitting hairs here but I want to make the distinction that at no point was an engineer making poor choices. Financial debt can be both good and bad. Good financial debt lets you take advantage of opportunities now that you wouldn't otherwise be able to afford, and you end up better off in the end. Bad financial debt leaves you worse off in the end. Taking on financial debt absolutely can be a poor choice. I don't see why these same qualities can't show up in technical debt as well. So sometimes engineers might be making poor choices, the point is to evaluate whether the debt is taken on to exploit an opportunity, evaluate whether you'll be better off for taking on that debt, and to ensure you pay it back in a timely manner.
• zugi 5y ago
  > "Technical debt is the burden that implementation choices may place on future development" True, provided we understand that those choices are not always conscious. I more commonly use the term looking back: some code technically works and at least minimally satisfies current use cases, but is hard to read and therefore hard to maintain or extend and bug-prone, so it needs to be refactored, improved, and/or modernized. Before the term "technical debt" existed, it could be hard for developers to convince management of the need to clean up existing code. It sounded like just some thing that crazy programmers wanted to do - spend time and money for something that delivered nothing new. Now managers can understand the need to pay off "technical debt."
  • a9h74j 5y ago
    > looking back .. minimally satisfies .. is hard to read Interesting. I wonder if there is an analogy to the first draft of a book. Everything needs "editing" -- that is a given. Some writing only needs line editing; some needs a restructuring, a rewrite, etc.
• geocar 5y ago
  > "Technical debt is the burden that implementation choices may place on future development." > With regard to its coherence, I say that it is empirically verified: it actually happens! Something happens, on this we can agree, but if you are making checkers and find out you need chess, it isn't that making chess is any harder than it was before you did anything -- so no, I would not agree that it placed any burden on future development. No, I think the real issue is that you have already paid for checkers and so you feel unhappy that your time (and maybe money) was wasted on checkers when you simply can't sell checkers because all along you needed chess. > The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that. The root cause of a problem and its broad consequences are separable concerns. The root cause is that you do not know what you want. Writing the crappiest version of checkers as quickly as possible is a great way to find out it is the wrong thing. Trying to write an "abstract board game" instead of just writing checkers so that the decision to choose checkers or chess could be delayed as long as possible is not: It assumes that it is mere time that informs us of what we want, rather than the feedback of seeing what we don't want. > it is completely reasonable to consider the situation where, say, I give a farmer cash in return for some produce at harvest time to be a debt We can fantasize about a great many things, including this, but software is not produce that is harvested and sold; you do not plant great software seeds to grow into great software trees. No, the debt is the cash that the farmer received, just like the debt is the cash you receive to write the software. The software itself is not debt and never was.
  • gmadsen 5y ago
    not all "technical debt" is wanting chess when we built checkers. it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess. the vast majority of software projects will have features/requirements that evolve after the initial design, it is a rabbit hole to try and guess all of those, but some things are just common sense but would add a little time to the first milestone. then you are in the position of tacking on things indefinitely making it a horrible tangled mess.
    • mook 5y ago
• austincheney 5y ago
  I prefer to think of it as, the more there is the more there is to fail. I apply that to the entirety of the application not just the tiny part I write.
• fsloth 5y ago
  "...everything we do that is 'technical' has ... consequences that go beyond the technical: The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that." Aha! But people do things just for technical reasons that don't affect the users in any way. One could claim that just refactoring code without changing anything is a "purely technical" exercise. What I've seen developers spend time on, that has absolutely no effect on end users in a large C++ codebase: * Changing old C-style string handling to std::strings * Change naming convention to uniform * Random formatting that should be done automatically but someone decided to do by hand * Sundry "modernizations" like replacing vanilla C++ loops with C++ range based for loops etc
  • thebean11 5y ago
    > One could claim that just refactoring code without changing anything is a "purely technical" exercise. The reason is still partly non technical; the goal is to make future changes less costly or less dangerous.
    • minitoar 5y ago
      Does it matter that they are less costly or less dangerous for technical reasons? lol
  • jungturk 5y ago
    To the extent that these changes actually improve the non-functional quality attributes of the system, those gains can be converted into business or customer utility. Improved maintainability => lower innovation costs, and those savings can turn into profits and/or happier customers. Improved security => reduced risk of exploit, and that improved posture can be turned into profits and/or happier customers. I acknowledged that not all changes of the sort you list do yield actual improvement in the quality attributes.
  • mannykannot 5y ago
    The examples you give look more like inefficient resource (developer time) allocation - AKA Yak Shaving - rather than technical debt. Nevertheless, people doing things for just technical reasons does sometimes create technical debt, as when doing so over-complicates the implementation to no observable end. So? If anything, these cases stand as counter-examples to the author's argument that technical debt is not technical.
• derefr 5y ago
  > It is completely reasonable to consider the situation where, say, I give a farmer cash in return for some produce at harvest time to be a debt. Being entirely-too pedantic about financial instruments: that’s a commodities future. Financially, it’s not a liability, it’s an asset: you’re owed something. It’s not really a good comparison to technical debt, which is at the very least clearly a financial liability of some kind — something that makes your company worse-off for having it. I think the author of the article, meanwhile, was interpreting “debt” to specifically be shorthand for “a loan taken out against future earnings.” Loans a company takes out give them both a short-term asset (cash flow) and a matching long-term liability (loan repayment.) Which seems kinda-sorta like what “technical debt” is motioning at: you get short-term gains (working code) but a long-term liability (the need to rewrite said code when its lack of robustness or unmaintainibility causes it to break down in the face of scaling challenges.) But this analogy is still pretty far off-the-mark, because: 1. You need to pay back a loan, or bad things happen to your company; but you won’t necessarily need to pay back technical debt — sometimes, despite your company scaling as a whole, the relevant software component just never needs to scale, and so it that particular technical landmine just never “goes off”; 2. loan repayments are predictable, and involve entering into contracts where you either conscientiously repay the debt month after month with low premiums, or you fail to make payments and the loan comes due. Technical debt is nothing like this; there’s no counterparty forcing IT companies into a default situation of paying down their tech-debt little-by-little. (Wouldn’t that be great?) Thus, a loan against future earnings is likewise a bad analogy for what technical debt “is.” Dredging around in finance for a more exact analogy for technical debt, a very close one might be writing and selling call options against your own company, where your share price hasn’t yet reached the strike price for these options. You would be raising short-term capital, but creating a future liability — in that when your share price hits the strike price (i.e. when your company grows), people would then have a growing incentive, commensurate with the growth in your share price over the strike price, to exercise their purchased call options by buying at the agreed strike price; and then some of those people — an unpredictable subset of them — would turn around and dump the resulting shares on the market at market value, lowering your share price. IMHO, the analogy is pretty okay because both scenarios are the same sort of “setting up a bomb for yourself that may go off at an unspecified time into the future, but only contingent on your company being successful, where you’ll have more resources to deal with it” problem. But on the other hand, you can’t really defuse having sold call options, in the way that you can “pay down” tech debt. (I guess you could try to buy back the call options — but the holders are under no obligation to sell them back to you. Whereas tech debt has no such willful resistance to being fixed.) So even this analogy, though better, isn’t a perfect one. Truly, though, although we can’t say we know what technical debt is specifically, we can probably be pretty explicit by just generalizing the term: all of what we call “technical debt” is in fact some kind of financial liability (in future engineer-hours needing to be spent.) So perhaps “technical liability” is, although vague, the best we can do.
• sorokod 5y ago
  "Technical debt is the burden that implementation choices may place on future development." Any choice you make now, may place a burden in some possible future.
  • ghoward 5y ago
    Some more than others.
    • sorokod 5y ago
      Absolutely, but the article complains about lack of rigor and this definition doesn't provide it.
• lowbloodsugar 5y ago
  Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need". Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work. More likely, however, is that the manager, who is not a structural engineer, sees a perfectly good bridge and orders the tanks across anyway, causing the loss of the bridge, the tanks, and the war. It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year. Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well. When Cunningham, for example, talks about what to do about debt, e.g. YAGNI, these are all good ideas: scoping. But the term "debt" is incorrect in this case. The term "debt" will only ever get a team in trouble as it indicates that the team is unwilling to confront the actual problem as engineering, but only as a broken metaphor.
  • yebyen 5y ago
    > It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment Well, those are two possibilities, but a third is that you don't need it because of one of several possible reasons. The debt metaphor still fails to hold up; the nice thing about accepting "technical debt" into your project is that you may never come upon a time where it needs to be paid off at all. Not all tech debt must be paid off. Usually only the highest priority tech debt can actually be paid down, and it doesn't always come with an interest cost. But when it starts to "come due," if you're an engineer in the hot seat, you can often (usually) tell pretty quickly just how much the "interest payment" actually affects your ability to deliver future iterations. Your "customers" or stakeholders can tell too, indirectly, when your estimates start outpacing their "very reasonable expectations."
• ingas 5y ago
  > Arguing over dictionary definitions is not going to lead to anything useful in this matter. > If we are going to be pedantic The whole article was about going to be pedantic over dictionary definitions. "Now, one major concern in academia is rigor. Academics like to get deep into a topic, examine the nuances, and bring clarity." I suppose it's hard to argue against that words in "technical debt" were chosen poorly: it's not debt and it's not technical. Maybe better definition is needed.