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

21–30 of 147 posts

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

#21

Post by afarrell »

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.

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

#23

Post by romwell »

KingOfCoders wrote: post #19

I tell all my coachees not to use "technical debt" outside of technology, if ever. Same goes for the phrase "refactoring", don't use it outside technology.

What do they try to use it for?

I've only ever seen these terms used in programming contexts

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

#24

Post by fsloth »

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…

I don't disagree with the article, and I don't disagree with you - I'm more of expanding the ideas you discussed.

I think the key here is indeed that technical debt should not be used as an excuse to write poor code.

But I think it may be hard to systematically tell apart code that was written intentionally fast and poorly, and code that just was written to explore the market.

It "is accepted" that the most of the cost a software comes from the maintenance period - adding bugfixes, new features, and just reading the code.

If the software can be moved from point A where these costs are high (including risk of things getting broken due to complex architecture) to a point B where they are lower, then I could say "technical debt is paid back".

Was the software in point A due to intentional shortcuts, or just because that's how we write software in an unfamiliar territory, is maybe besides the point in gauging the practicality of the term.

The "technical debt" gets anyway accumulated due to the empirical quality of most of software engineering process.

I think this is the most critical thing people should realize - don't take short cuts unless the house is burning down - but do try to explore the problem space fearlessly.

The exploration is due to incomplete understanding of the end user needs. And sometimes you can't really explore that space without delivering something to the user.

But!

I think the exploration phase does not necessarily need to incur technical debt if it's done using prototypes that won't end up in production (yeah yeah like that's ever happened but in theory...).

In this case the deliverable will be just used as a template for the actual product development, with the result that the product may be in a more mature state from the get go, and hence, have less debt from the start.

Should the exploration be done with prototypes or actual vertical slices of production software? I suppose this depends on the situation. Sometimes the problem is actually so hard that you need to deliver a build based on an actual production codebase no matter what.

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

#25

Post by dgb23 »

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…

That’s because abstraction enables a mental model and a language around the translation of your domain to computation.

When people dont understand or agree with a model, then you get these conflicting perspectives on what constitutes correct or incorrect expression.

In some simple cases it’s clear that there is a problem, or debt, when there is a clear semantic violation, a code smell or similar. But often there are multiple ways of expressing the same.

Quantification of unnecessary complexity can only be done after you know what is necessary and how you express that.

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

#26

Post by [deleted] »

dgb23 wrote: post #25
gHeadphone wrote: post #4

Earlier quoted context omitted.

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…

That’s because abstraction enables a mental model and a language around the translation of your domain to computation. When people dont understand or agree with a model, then you get these conflicting perspectives on what constitutes correct or incorrect expression. In some simple cases it’s clear that there is a problem, or debt, when there is a clear semantic violation, a code smell or similar. But often there are…

[deleted]

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

#27

Post by KingOfCoders »

romwell wrote: post #23
KingOfCoders wrote: post #19

I tell all my coachees not to use "technical debt" outside of technology, if ever. Same goes for the phrase "refactoring", don't use it outside technology.

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

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

#28

Post by andi999 »

arcturus17 wrote: post #7
amelius wrote: post #6

Earlier quoted context omitted.

Nice analysis, but I think you missed the most important difference between real debt and technical debt: with real debt you owe someone else; with technical debt you owe yourself.

Not necessarily as it is passed down generations. This is in fact when it becomes more painful. Regardless, technical debt was always clearly a metaphor. I can imagine many other metaphors where one may owe something to oneself, eg, “sleep debt”. Who cares if it conforms to the definition of the Bank of England?

Next article could be 'butterfly is not a fly; it is not even making butter.'

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

#29

Post by tylerhou »

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…

> "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"

Nit: Not the entire 3 days is interest in this analogy because you are also paying down principal.

For example: "Implementing the database layer properly would have taken 5 days; because we took shortcuts (for business reasons) it only took us 3 days. Now we have to implement feature X, and because of our previous shortcut feature X will take 4 days, so 3 + 4 days in total. But if we had implemented the database layer properly in the first place the new feature would have only taken 1 day, so 5 + 1 days in total."

Then in the three-day payment, two are towards principal (that's how much you "borrowed" previously), and one is towards interest.

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

#30

Post by stared »

Why do we ever need to do write tests if the code works?

Why do we create encapsulated build setups if everyone from the team knows how it install it on their machines anyway?

Why do we waste time on writing documentation?

And above all: if during a three-day hackathon we can create a game, why does it take months or years to create a publishable one?

Post reply on HN