Hacker News Reader

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 debt" to which everyone intuitively agrees it's a problem.

But yes having people with the competence to actually understand the clear cut issues also making the prioritization would be nice.

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.

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 code will be bad, but it was useful for its purpose.

It only becomes debt when faced with the results of your past mistakes you choose short term gains over long term profit, i.e. you know the code is shit but you keep building on it instead of dedicating time to refactor things because you need a feature yesterday instead of tomorrow.

Often this last decision comes from management, not the engineer that figure out things aren't going well.

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.

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.

I think you read the wrong intentions in Wards definition. It was never about short-term goals.

It was about building something to gain understanding of the problem space and deliberately taking the time to incorporate new insights into the code. Not doing so would make adding functionality more difficult long-term. Obviously not incorporating such learning can be seen as a short-term objective, but it is more about being actually aware that you need some time incorporating lessons learned or otherwise there are consequences.

Your definition of technical debt is just making trade-offs and that just is that: explaining the actual trade-off and there is no need to talk about technical debt. It’s just a bullshit empty label.

I think we'll just have to agree to disagree. Specifically about this part:

> Obviously not incorporating such learning can be seen as a short-term objective, but it is more about being actually aware that you need some time incorporating lessons learned or otherwise there are consequences.

Why would someone take the time to do a learning activity and then not only ignore the results of said activity but actually deliver the knowingly bad attempt? The important part is why someone would do this, the motive.

There is only one reason to do so: they don't want to spend the time and or resources, or need to spend them somewhere else. That's a trade-off of course, so technical debt always involves making a trade-off, even in Wards definition.

I also vehemently disagree it is an empty label, it describes quite nicely the concern through analogy: paying interest (slowing down development) on debt (throwaway code that was kept). There are other trade-offs that are nothing like this.

I understand your point perfectly, but it is only valid at the abstract level Ward defines it.

However what people did is ignore his actual point and ran with the ‘debt’ analogy and now we call ‘not applying patches for a year’ technical debt whereas this is clearly just bullshit.

And for more serious topic, every trade-off somehow gets called TD. Every deviation from some platonic ideal is TD.

It just is extremely unhelpful for any meaningful discussion.

I see your point and I agree. The term has become too diluted. I don't have a good solution to the problem. Perhaps dropping the term is the way to go, but I'm not sure what I'd replace it by. I guess we can start saying "we have too much throwaway code left in production".

You just hit exactly on the right topic: I think we don’t need a replacement. Your example is perfect, just name the actual issue and deal with it. That’s frankly all I really propose in the end.

Also, I think that some decisions are to be made within the development team. It is not for the business to tell them how to develop and keep the code base healthy. Some thing you just do and they are just cost of doing business.

Business wants features and never wants to say, ok do maintenance tasks for a month. I’ve seen it play out, a lack of critical maintenance imposed by product caused days of expensive outages across multiple customers.

Thanks for being my sounding board :)

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.

> 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.ycombinator.com/item?id=29727487

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.

%s/debt/bugs/g

Really the concept doesn’t add anything.

> I think we need less bullshit and more environments where people can openly admit to and discuss mistakes

Are we talking about mistakes?

Suppose that I build a system that has capacity 1M when the usage is 100 and growing at 10% a month. That system will be inadequate eventually, but it won't be for some time.

Should I have built a system with capacity 10M instead? Would it have been horrible if I'd only built for 100k. (It's unclear why those 10xs are different.) Should I have built a system with "infinite" capacity? Does the answer depend on how much each alternative costs?

This discussion is fine in and of itself. This discussion and any outcomes have nothing to do with technical debt.

If stakeholders are aware of design decisions and related cost + understand the potential trade-off, that’s it.

No need to add concepts like technical debt. And this example would not even be technical debt according to Ward Cunningham’s definition.

It's not clear how to distinguish my example from every other shortcut that people do to get things out the door. (It's not the numbers - growth can jump to 100% if marketing gets its act together.)

While Ward Cunningham may have introduced the term, his definition is obviously not the one that most people use, so it's pretty irrelevant.

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.

I think I agree. It is used as a euphemism for bad code.

However, I feel there is a need for an iterate approuch when programming, and I would very much call not going back fixing stuff accruing technical debt. No matter if the fault is "OK" and part of the natural flow of programming or incompetence.

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.