How to approach and prioritize technical debt • Hacker News Board

Re: How to approach and prioritize technical debt

#31

Post by kahmeal » Mon, Jan 31, 2022, 11:19 PM UTC

joshfee wrote: post #25

lowbloodsugar wrote: post #22

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…

What you describe is not what I've experienced with debt. Usually it is a conflict where short term goals and long term goals are at odds with each other. Using your bridge analogy, its more like "We only need an infantry bridge right now, but we know that in a year we need to support tanks". Well we can either spend $2m to build the tank bridge now, or we can spend $1m today for the infantry, but in a year you'll ha…

This is tech debt.

Re: How to approach and prioritize technical debt

#32

Post by kahmeal » Mon, Jan 31, 2022, 11:21 PM UTC

thinkmassive wrote: post #24

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

> The best way to deal with tech debt is to never use the term in the first place. At the very least, give it a more specific name. A Reforge article[0] that was shared here about a month ago[1] suggests these six categories: - maintenance debt - developer efficiency debt - stability debt - security debt - technical product debt - decision debt [0] https://www.reforge.com/blog/managing-tech-debt [1] https://news.ycom…

All this granular bullshit is entirely too much overhead and an unnecessary layer to "manage" imo. "Tech debt" and handling it should be part of your culture and by default included in the scope of any estimate that touches something affected by it. You negotiate out of addressing it, not into it.

Re: How to approach and prioritize technical debt

#33

Post by louwrentius » Mon, Jan 31, 2022, 11:39 PM UTC

ess3 wrote: post #7

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

I agree with you. But I guess the problem stems from having to prioritize between building the next shiny thing or actually going back and fixing the problem. Even worse is that many of these problems have rather low short-term impact and a much larger long-term impact, which makes it even harder to justify/explain to the person making the prioritization. It's much easier to hide it behind the facade of "technical de…

Having to resort to bullshit concepts to deal with discussions like this only shows a bigger problem.

And maybe we should not let people decide priorities who don’t understand the problems at hand and the trade-off to be made.

Re: How to approach and prioritize technical debt

#34

Post by louwrentius » Mon, Jan 31, 2022, 11:43 PM UTC

sirwhinesalot wrote: post #20

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

Having bad code is not technical debt, I've seen it used that way but it's wrong, since there was no debt accrued, you just wasted all your money in Vegas. It was a bad decision but not "debt". The analogy doesn't work in that case. Bad code is something that happens, even to good devs. Sometimes you just don't have a clear picture of the problem and cobble something together to try and learn how to approach it. That…

This is NOT the definition of TD as Ward Cunningham described it. It was never about trading short-term goals for long-term slowdowns.

It was about building software with the specific goal as to learn about the problem domain and the concepts. It is focused on high-level architecture, understanding and discovering the foundational structure.

And once you gain new insights NOT reworking code to align with new insights would result in ‘real’ technical debt.

Re: How to approach and prioritize technical debt

#35

Post by louwrentius » Mon, Jan 31, 2022, 11:45 PM UTC

thinkmassive wrote: post #24

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

> The best way to deal with tech debt is to never use the term in the first place. At the very least, give it a more specific name. A Reforge article[0] that was shared here about a month ago[1] suggests these six categories: - maintenance debt - developer efficiency debt - stability debt - security debt - technical product debt - decision debt [0] https://www.reforge.com/blog/managing-tech-debt [1] https://news.ycom…

%s/debt/bugs/g

Really the concept doesn’t add anything.

Re: How to approach and prioritize technical debt

#36

Post by louwrentius » Mon, Jan 31, 2022, 11:48 PM UTC

michaelfeathers wrote: post #6

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

A term I use to recenter on Ward Cunningham's concept is 'Design Lag' - How far is the code behind your current understanding of the problem?

That is something I can get behind.

But the rest of the world has taken the concept of TD and warped it to mean ‘my fuckup with a more neutral label’.

Check definitions when you talk about TD with someone.

Re: How to approach and prioritize technical debt

#37

Post by louwrentius » Mon, Jan 31, 2022, 11:50 PM UTC

twh270 wrote: post #10

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

Absent a real situation with real people, I agree. In practice, however, many developers work in a low trust environment where management is quick to bring out the stick for any (perceived) mistake or error. In that scenario, it's understandable to not want to expose your mistakes.

So in practice Technical Debt is exactly the kind of bullshit talk in a low-trust asinine work environment. That doesn’t really validate the concept.

Re: How to approach and prioritize technical debt

#38

Post by coyotespike » Mon, Jan 31, 2022, 11:56 PM UTC

suncore wrote: post #8

Here's a few observations (after long time experience and involvement in research around technical debt): 1) It is impossible to avoid gathering technical debt. The code will deteriorate in one way or another. You need to prepare to fix it since you can't avoid it. 2) It is so extremely difficult to make a correct "risk assessment" on technical debt so you should avoid doing so at all. You will just end up arguing al…

This is great, especially 3) which implicitly makes a business case for reducing tech debt (useful for communicating with the rest of the org), and also helps steer us toward debt that actually matters.

Re: How to approach and prioritize technical debt

#39

Post by AdrianB1 » Tue, Feb 01, 2022, 12:26 AM UTC

louwrentius wrote: post #4

The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…

In my case technical debt does not involve blame or any guilt of any sort, it is just the reality of having code that is 20 years old running on newer machines and software versions (ex: SQL code); all this code was fine when it was created, so there is no blame, but it is no longer fine for these days and there is no better term to describe the situation than tech debt. I would be happy to use a better one if I find one.

Re: How to approach and prioritize technical debt

#40

Post by sirwhinesalot » Tue, Feb 01, 2022, 1:29 AM UTC

louwrentius wrote: post #34

sirwhinesalot wrote: post #20

Earlier quoted context omitted.

Having bad code is not technical debt, I've seen it used that way but it's wrong, since there was no debt accrued, you just wasted all your money in Vegas. It was a bad decision but not "debt". The analogy doesn't work in that case. Bad code is something that happens, even to good devs. Sometimes you just don't have a clear picture of the problem and cobble something together to try and learn how to approach it. That…

This is NOT the definition of TD as Ward Cunningham described it. It was never about trading short-term goals for long-term slowdowns. It was about building software with the specific goal as to learn about the problem domain and the concepts. It is focused on high-level architecture, understanding and discovering the foundational structure. And once you gain new insights NOT reworking code to align with new insights…

I'm not concerned with Ward Cunningham's original description. Keeping the prototype that was used to learn about the problem as the actual solution to the problem (without refactoring according to the new insights) is most certainly trading short-term goals for long-term slowdowns and a common occurrence.

There's no such thing as a prototype in practice, unfortunately from my experience. If management sees something half working then they don't want to toss it out.

These days the concept of technical debt has simply expanded to all other situations where this tradeoff occurs, where the knowledge is already partially there but the decision to go with the "prototype" (which is not a prototype because it's already known to be a dead end) is still made.

TL;DR: Tech debt occurs any time you write throwaway code to achieve some short term result, which you don't clean up later (pay the debt). Ward Cunningham's original definition is an instance of this more general definition, his is unnecessarily specific IMO.