Technical debt is not debt; it’s not even technical • Hacker News Board

Re: Technical debt is not debt; it’s not even technical

#131

Post by lowbloodsugar » Fri, Jul 30, 2021, 5:21 PM UTC

mannykannot wrote: post #68

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 implementation choices may place on future development." Nothing in the article leads me to think that this is either incoherent or irrelevant. With regard to its coherence, I say that it is empirically verified: it actually happens! The claim that it is not techn…

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.

Re: Technical debt is not debt; it’s not even technical

#132

Post by jjk166 » Fri, Jul 30, 2021, 5:21 PM UTC

gHeadphone wrote: post #4

theamk wrote: post #3

I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title. Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept…

You make a god point about the generally accepted meanings for terms for technical debt. However, there are lots of companies ive worked in (and more I know of) that try to scientifically calculate a numerical value for Technical Debt. At best, it's a metaphor, a mental aid to understand a loose concept. Any attempt to calculate implies that there is some 'best solution' that should be achieved. However, this almost…

While there may not be some universal best solution, that does not mean all solutions are created equal. You can certainly look at two options and say "this one will take about half as much effort to fix later" or "it'll take as much time, but we can put a less skilled person on it." Maybe putting a number on it doesn't mean anything in absolute terms, but it's still useful in relative terms.

Re: Technical debt is not debt; it’s not even technical

#133

Post by rmetzler » Fri, Jul 30, 2021, 5:36 PM UTC

Retric wrote: post #71

fsloth wrote: post #62

Earlier quoted context omitted.

I think in general writing code based on hypothetical requirements that never materialize is just wasteful. And leads to bad code. You can ship good code fast. Shipping slow is not a guarantee of good code. I think the pathology here is defending "sloppy" or "negligent" code by the need to ship fast, when in fact you probably could ship as fast with cleaner code, but the coder just could not care enough.

This isn’t about knowing what changes will be made just that change is inevitable. Technical debt arises because it’s faster to write brittle code. The problem with brittle code is it makes any change more difficult. The most obvious example is variable names without semantic meaning. The compiler doesn’t care if you’re using “asdf” but such choices collects its pound of flesh every time anyone messes with that secti…

Yes, I 100% agree and would like to add to your argument.

Another example of technical debt is when you write code without tests. You’ll probably finish much faster in the first week or two and then the manual testing will take more and more time. But how often did we see code bases without tests? All the time! And the managers don’t realize how much money they could save by focusing more on quality instead of features.

If you think you‘ll just implement this one thing and then never touch the code again, chances are high you‘ll just hack up the thing and copy paste some code everywhere until it kind of works. This is increasing technical debt, you take out a loan and someone in the future has to pay it back IF they want to make a change. But this is almost always the case, even if you don’t know it now.

My definition of technical debt I wrote down before reading the article: technical debt is the inability to make changes due to not making changes (on a conceptual layer) before.

Re: Technical debt is not debt; it’s not even technical

#134

Post by lobocinza » Fri, Jul 30, 2021, 7:07 PM UTC

gmadsen wrote: post #102

JKCalhoun wrote: post #90

Earlier quoted context omitted.

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 acc…

I think you are taking it personally, tech debt usually isn't the fault of individual engineers. It is leadership who chooses to value initial short term speed over extensibility, maintainability, etc. sometimes it is obvious to the engineer that this will cause problems in a few months, but the first deadline is in a few days, and that's all leadership cares about.

This is something that I see "daily" currently working as a contractor on web development. Frameworks like Bootstrap are used to quickly/cheaply deploy a site but by not doing things "properly" from the beginning it creates a debt to be paid later with compounds.

I dislike working with Bootstrap projects but I understand that "getting into debt" sometimes is unavoidable. And debt isn't necessarily a bad thing.

Re: Technical debt is not debt; it’s not even technical

#135

Post by ryukafalz » Fri, Jul 30, 2021, 7:32 PM UTC

JKCalhoun wrote: post #90

phkahler wrote: post #84

Earlier quoted context omitted.

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.” T…

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 acc…

> I've always assumed engineers (myself included) write code to the best of their abilities to solve a given problem at the time.

In your own personal project, I'd probably agree. But in my experience in a work project there can often be imposed deadlines or project changes that result in engineers writing code that they themselves know is suboptimal even at the time.

In other words, the sort of change that might include a comment like "I know this isn't the best way to do this but don't have time to do it the best way right now." It's not the best I can do overall, but it's the only thing I'm able to do for whatever reason. That's the kind of thing I'd call tech debt.

Re: Technical debt is not debt; it’s not even technical

#136

Post by AlbertCory » Fri, Jul 30, 2021, 7:38 PM UTC

billytetrud wrote: post #128

AlbertCory wrote: post #126

I am deeply, deeply cynical about the notion of "technical debt." Why? Because it is inextricably tied to career ambitions. There is no promotion benefit to just "paying back" a small debt by fixing some kluge, while there is enormous benefit to leading a rewrite. Furthermore, once a rewrite is in play, the temptation to "just fix" a bunch of other things and add some new features that were hitherto impossible is irr…

Rewrites aren't fixing technical debt. Rewrites are letting your last version declare bankruptcy

Indeed. I was saying that a "debt fix" release quite often turns into a rewrite, no matter what the original justification was.

Re: Technical debt is not debt; it’s not even technical

#137

Post by phkahler » Fri, Jul 30, 2021, 7:39 PM UTC

JKCalhoun wrote: post #90

phkahler wrote: post #84

Earlier quoted context omitted.

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.” T…

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 acc…

I've written code that I knew could be better when I wrote it. "Better" can mean a number of things. More readable, more efficient, more self contained, lower cyclomatic complexity (whatever TF that means).

I never intended to put shame on tech debt. It's usually a now vs later (or never) tradeoff.

Re: Technical debt is not debt; it’s not even technical

#138

Post by zug_zug » Fri, Jul 30, 2021, 8:06 PM UTC

Sounds like there is rightly a lot of mistrust of technical debt (rightly because about half of the things one engineer calls technical debt "Rewrite that service in go" another engineer calls perfectly fine).

Perhaps it's best for everybody involved if we define "hard technical debt," which meets the highest criteria.

1. The interest is in measurable engineer-time (not risk, not user-experience, not sales, not satisfaction). E.G. "Every time we deploy it takes the scripts 30 minutes to run, and I can't switch focus for those 30 minutes"

2. The capital is in measurable time. "It would take 15 work hours to fix that script, with planning, debugging, documentation, etc"

With those two, we can calculate the annual interest rate at 173% (at 1 deploy per week).

This would help separate people who love doing rewrites because it's fun to put their name on things from actual "this is wasting my time every day" concerns.

Re: Technical debt is not debt; it’s not even technical

#139

Post by craftinator » Fri, Jul 30, 2021, 8:44 PM UTC

JKCalhoun wrote: post #90

phkahler wrote: post #84

Earlier quoted context omitted.

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.” T…

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 acc…

> 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.

Another way of looking at technical debt, that I unfortunately must use regularly, is debt accrued by not updating systems. I work with hardware and software that is, in some cases, from the 80's. As these machines age, they become more and more likely to break. The longer we wait to replace them, the more value their initial investment is worth, but also the greater the chance that production will be halted for months while we try to design and implement a new system. So this is technical debt accrual as a function of time, not as a function of development speed.

Re: Technical debt is not debt; it’s not even technical

#140

Post by yebyen » Fri, Jul 30, 2021, 9:05 PM UTC

lowbloodsugar wrote: post #131

mannykannot wrote: post #68

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 implementation choices may place on future development." Nothing in the article leads me to think that this is either incoherent or irrelevant. With regard to its coherence, I say that it is empirically verified: it actually happens! The claim that it is not techn…

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 d…

> 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."