Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

markgreville.ie

Post reply on HN
Print view View original

41–50 of 147 posts

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

#41

Post by lixtra »

dub wrote: post #35

Much of the time "technical debt" seems to be a euphemism for bad engineering The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt" In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our bus…

Maybe it makes more sense to look at concrete examples. Twitter using the db as router (and rails in general), was a reasonable decision for the MVP. They got it fast and cheap.

For social media kind of traffic it became inadequate at some point and the debt had to be paid (and thanks to success was easy to pay).

To me a smart use of technical debt.

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

#43

Post by pdimitar »

> Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense.

This really is NOT how you start an article. You only come across as needlessly assertive and arrogant.

> Nobody explained technical debt; we assumed it was a fundamental property of the work.

Total BS. Literally every manager I ever addressed in a sentence where "technical debt" was mentioned did question what exactly it is and why do we need to address and "repay" it. Where is the author of the article living? Not with us the programmers here on the ground, that's for sure.

> Now, one major concern in academia is rigor.

Ah, so now it's about academia and its definition. I'll cut him a deal. Bring your academics to my former customers and see if they can override management's idea of a technical debt. Succeed 5 times and then I'll bow to you and accept your definition. Until then you're just an annoyance like that guy on parties who is always going around telling people "well ACTUALLY you are using the wrong term".

Doesn't matter what the dictionary says, people. It matters what most of the people think a word means. It matters what most of the people do when faced with the word. Why is this so hard to accept for many?

--

No, I haven't read the entire article. It smells of intellectual elitism and arrogance a mile away. The author must work on his tone.

Technical debt, whatever your definition of it is, is still a natural property of tight schedules. That's it. We can all go home now.

I wouldn't expect an academic to understand realities of schedules and budgets though.

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

#44

Post by Tade0 »

viseztrance wrote: post #39

> Debt repayment has one vital characteristic: it is easy to understand If it were this easy you wouldn't see so many people taking on so many unnecessary debts. Technical or otherwise.

I'm in the process of searching for an apartment to buy and the formula for calculating the installment amount, while using only basic operations, is anything but simple.

Chiefly the answer to the question "how will this amount change if the interest rates go from effectively zero to 6%, which is the 30-year average?" is not straightforward.

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

#46

Post by dub »

lixtra wrote: post #41
dub wrote: post #35

Much of the time "technical debt" seems to be a euphemism for bad engineering The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt" In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our bus…

Maybe it makes more sense to look at concrete examples. Twitter using the db as router (and rails in general), was a reasonable decision for the MVP. They got it fast and cheap. For social media kind of traffic it became inadequate at some point and the debt had to be paid (and thanks to success was easy to pay). To me a smart use of technical debt.

A concrete example might be choosing a database and schema for a public-facing product with the hope that it'll become popular but with no architectural contingency plan whatsoever for how to scale up that data storage in the event of success

Certain qualities or features like horizontal scalability and security can be relatively inexpensive to design in at the beginning and immensely expensive to try to tack on later once a system is already in wide use.

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

#47

Post by pdimitar »

afarrell wrote: post #21
charles_f wrote: post #10

A) big part of the article is about the fact that the current tribal meaning of the term deviated from the meaning that the first person to use it had. This is somewhat of a semantics argument, like "hey you're using that in a commonly accepted way but Ward C didn't mean that so you're wrong". B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at so…

> This is somewhat of a semantics argument It is important to occasionally have arguments to clarify semantics so we maintain the meaningfulness of our language. Otherwise, we lose the ability to communicate. Some people believe that meaningful communication is unimportant. Those people are wrong.

We should periodically make sure we use common terms, yes, but I find the author's tone hugely inappropriate. He seems a bit rebellious against the notion of "technical debt to the masses means something else than it means to me".

Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is.

Furthermore, what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.

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

#48

Post by xondono »

dub wrote: post #35

Much of the time "technical debt" seems to be a euphemism for bad engineering The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt" In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our bus…

I disagree.

Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle.

Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot of buildings have little spaces reconverted to closets just because there was leftover space there. That's technical debt, you know the "best approach" (according to waterfall engineering) would be to find out how things will work and then build it, but you'd rather write "IOU" on that section and move on to the important bits. You can then solve the kinks with plasterboard.

The best example of technical debt is code that doesn't scale. You know you should write your code to support 1M users, but you currently have ~100 users. Instead of spending a month serving 990k users you don't have, I would say it's good engineering to solve the problem for say 10k users if that means you'll spend a week, and have the rest of the time to solve other more pressing concerns.

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

#49

Post by romwell »

KingOfCoders wrote: post #27
romwell wrote: post #23

Earlier quoted context omitted.

What do they try to use it for? I've only ever seen these terms used in programming contexts

I often see people try to use it as a lever to prioritize technical changes, migrations or refactorings against business features. But the result is just that people outside technology think technology is clueless and "they have debt, whatever that means".

Ah. Easy problem.

"We have technical debt to repay" = bad

"We outgrew the choices we made that allowed us to grow fast, and need to refresh our product to sustain the growth rate" = actually means what we want to say

Makes it clear that prioritizing new features will come at the expense of growth. Which is ultimately what the stakeholders really care about.

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

#50

Post by spottybanana »

I think the whole term "technical debt" has developed as a part of business and technical team negotiations. The technical team prefers to improve their own job comfort, doing tasks that make their job more comfortable and stress-free, but doesn't really add business value in terms of revenue and profit. The business side isn't aligned against this work, but their priorities are on the other side. "Technical debt" is a great term from negotiation viewpoint, because for clueless business leaders it gives the impression that the tech team is paying debt when it is doing this low-risk low-reward activity, when it actually isn't.
Post reply on HN