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

71–80 of 147 posts

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

#71

Post by Retric »

fsloth wrote: post #62
rorykoehler wrote: post #33

Earlier quoted context omitted.

It's not poor code it's just code that prioritises shipping now over writing for some hypothetical future state.

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

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

#72

Post by pdimitar »

sethammons wrote: post #70
pdimitar wrote: post #43

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

I really like the opening question because it is a forcing action that will allow you to agree or disagree better. My initial thought was that, as academics, they were going to be aloof and out of touch. However, as a boots on the ground dev who has worked from start up through multi-thousand employee public company, and who has held leadership roles, I agree with the article. Maybe if you read it, you would too.

Do they address the pressure from above?

I've given very compelling arguments to address tech debt that made a room of 20+ people in management smile and nod approvingly. Yet higher leadership still overruled me (and them).

If not, I am not convinced the article has anything to offer me in particular.

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

#73

Post by ape4 »

Wikipedia has a reasonable definition: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2]

https://en.wikipedia.org/wiki/Technical_debt

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

#74

Post by majkinetor »

AstralStorm wrote: post #60
majkinetor wrote: post #38

TLDR > Cunningham: I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial. Technical debt is not about technology, but about better understanding of functional domain, after which you should refactor your current implementation to better reflect reality in the sense that there is a more clean abstraction an…

That's just one part of it. In modern development practices you have dependencies, each being at risk of getting outdated or insecure. Even if it's the programming language, build environment or OS. No abstraction will save you from this.

That is not technological debt according to the this article. Its not about outdated dependencies.

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

#75

Post by AnIdiotOnTheNet »

ape4 wrote: post #73

Wikipedia has a reasonable definition: a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2] https://en.wikipedia.org/wiki/Technical_debt

I would disagree in that I would say it isn't necessarily the 'easy' or 'limited' solutions, but basically any solution that, in retrospect, is now a limiting factor in your development. Overengineering is just as bad as under if it later limits your performance and/or flexibility.

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

#76

Post by jameshart »

amelius wrote: post #6
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…

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.

I had an aha moment a few years ago when I realized that technical debt is not taken out by the development team; the development team are the ones making the loan. The debtor is the product/sales team, who got their feature early but now have to pay a little more (in delay or lack of functionality) for every other feature.

Ideally, a dev team delivers feature value at a particular sustainable rate. Think of that as your product team’s ‘income’. Now, if the product team needs a feature early, they can have it if they take out a loan - they can have the feature built without sustainable integration into the codebase - but it will reduce their effective income because future feature delivery will be slowed by the friction of the incurred debt - the interest payments.

Don’t let the product owners make you feel like you have to deal with the burden of debt they took out! They owe you the time to clean up the mess they demanded to get their features faster.

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

#78

Post by yCombLinks »

bertylicious wrote: post #53
pdimitar wrote: post #43

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

The time it took you to write this rant would have been enough to finish reading the article...

I for one enjoyed the rant

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

#79

Post by mikewarot »

So it's really not technical debt, but rather cognitive debt? In Rumsfeldian, it is the difference between the current known knowns and the previous known unknowns. That hard won knowledge should be plowed into the source code, via refactoring, before it is lost.

Source code is the expression of knowledge about a problem that happens to be machine readable.

Test code is the expression of knowledge about how things can go wrong solving the problem, and it happens to be machine readable as well.

I agree that a sad aspect to this is the use of a money metaphor. Once the Silicon Valley types hear a finance term, they lock on to it as something to be optimized, and deployed as a tool. It leads people astray.

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

#80

Post by Joker_vD »

imbnwa wrote: post #67

I know we loathe these kinds of comments but that site was hard to read with that thin font and crazy low contrast

Thin, light-grey letters on white background indeed have poor contrast, but then again: thin, bright-red letters on white background have excellent contrast but are arguably even worse.
Post reply on HN