[phkahler]

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]

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]

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

[gmadsen]

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.

[lobocinza]

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.

[craftinator]

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

[hattmall]

Writing code to the "best of your ability" is something I've seen create a lot of problems because after you get about 75% done you probably realize how to do it better, and that happens repeatedly. In extreme cases I've seen mid-project framework changes multiple times.

Writing code that isn't great but works in order to ship a product in a timely manner incurs technical debt because you may have to do more work in the future to fix it once it is in use. But ideally your project is generating real income on that technical debt so it's probably better to have something to works right now vs something that's going to be perfect when it's done, eventually.

[ryukafalz]

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

[phkahler]

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.