6 ms·

I’ve never seen technical debt referred to such at any workplace - all the time I’ve seen the term used to refer to poor or outdated design decisions that compr

I’ve never seen technical debt referred to such at any workplace - all the time I’ve seen the term used to refer to poor or outdated design decisions that compromise the ability to deliver on business objectives in serious ways. Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues before it is too late and everything is on fire all the time. Be wary of any such blanket assumptions in engineering.

waterlink 8y ago
> Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues Would you agree that we should think about specific issues that are slowing us down, and fix them one by one, starting from the worst ones? (worst in sense of biggest slowdown/pain levels)
- Bahamut 8y ago
  Sure, but my point was one should consider complaints as signal that the situation should be monitored/investigated so that the general outlines of an actionable plan can be crafted if there are potential areas of risk, or in the most serious situation, an actual plan. Blanket painting of a class of complaints doesn't help them or you accomplish business objectives better long term.
  - ghiculescu 8y ago
    We agree more than you think. Most complaints about tech debt are not worth actioning, but that doesn't mean you shouldn't listen to all of them and try to filter the signal from the noise.
repolfx 8y ago
Lucky you :) I think there's a reason that post is currently voted to the top. I'm lead engineer on my startup's project, not the CTO but reporting directly to him. Team of about 30. There are of course many legitimate things that can be described as tech debt, files that got too large and convoluted over many patches by many people, that sort of thing. But I find I have to watch out for the concept of "tech debt" because a few engineers will abuse it if given the chance. For instance they will insist that code that was just written fresh by a colleague is "tech debt" because they would personally have written it differently, when there are no meaningful differences between the two approaches. They can claim that a design they don't understand the reasons for immediately (regardless of whether it's documented) is tech debt. They can claim any feature they don't personally want to do or which is perceived as hard work will create tech debt. And so on. I wrote the initial code and I'm close enough to the codebase still to be able to fairly thoroughly examine claims of tech debt. I'd say most such claims are actually not a big deal and do not justify any non-trivial investments of time to resolve. Moreover the sort of engineers who pay down more than their fair share of legitimate tech debt are invariably the ones who complain about it the least.
- thiagooffm 8y ago
  It might be upvoted because people find it catchy. But if you have ever wrote code in your life, you know that person who wrote about it got no idea whatsoever about software development. I'll upvote it as well, as it is possibly the thing with the least amount of intelligence that I've read so far in my life.
- fhood 8y ago
  Sure, but are you differentiating between run of the mill bitching, and actual serious concerns? Because if I whine about x internal library in stand up, that is probably not important. But if I come to you in person and tell you that x internal library is introducing more bugs than saving time, I probably really mean/am concerned by that.
  - Fire-Dragon-DoL 8y ago
    Freshly written code can easily be technical debt. An example of this could be "put a junior in a comolex piece of code and let him add a feature". That feature will work and probably is technical debt, because of bad design choices. I've been on the other side of this. I was developing the frontend part to a series of http endpoints and my colleague was working on the http endpoints. He was creating some terrible code but I had no power at the time. When he was done, the code was functional, had various bug and a new feature was needed. I spent a week studying the code and managed to add a feature, which however was buggy due to how the code was written originally. I fixed all the bugs, and ended up totalling 4 weeks of work. This colleague was let go after this due to a series of circumstances, so I became the owner of the code. Then a new feature needed to be added but to do that i'd need to change various things in such code. Two weeks in, I still wasn't done. At some point I asked to be able to rewrite the code. I did, it took 2 weeks and was able to add the feature easily. I'm no genius but code that cripples you down from the get-go is tech debt. Tech debt is failure in software design, which ends up in unmaintainable code. I'd listen to anyone pointing at tech debt in my code, it means my code sucks, I made a big professional mistake and I need to correct it. There is also voluntarily added tech debt, that's the one added by taking shortcuts. As long as you don't build new features on top of it, you are good.

waterlink 8y ago

> Complaining about technical debt complaints is an easy way to potentially bias oneself against recognizing real issues Would you agree that we should think about specific issues that are slowing us down, and fix them one by one, starting from the worst ones? (worst in sense of biggest slowdown/pain levels)

Bahamut 8y ago
Sure, but my point was one should consider complaints as signal that the situation should be monitored/investigated so that the general outlines of an actionable plan can be crafted if there are potential areas of risk, or in the most serious situation, an actual plan. Blanket painting of a class of complaints doesn't help them or you accomplish business objectives better long term.
- ghiculescu 8y ago
  We agree more than you think. Most complaints about tech debt are not worth actioning, but that doesn't mean you shouldn't listen to all of them and try to filter the signal from the noise.

repolfx 8y ago

Lucky you :) I think there's a reason that post is currently voted to the top. I'm lead engineer on my startup's project, not the CTO but reporting directly to him. Team of about 30. There are of course many legitimate things that can be described as tech debt, files that got too large and convoluted over many patches by many people, that sort of thing. But I find I have to watch out for the concept of "tech debt" because a few engineers will abuse it if given the chance. For instance they will insist that code that was just written fresh by a colleague is "tech debt" because they would personally have written it differently, when there are no meaningful differences between the two approaches. They can claim that a design they don't understand the reasons for immediately (regardless of whether it's documented) is tech debt. They can claim any feature they don't personally want to do or which is perceived as hard work will create tech debt. And so on. I wrote the initial code and I'm close enough to the codebase still to be able to fairly thoroughly examine claims of tech debt. I'd say most such claims are actually not a big deal and do not justify any non-trivial investments of time to resolve. Moreover the sort of engineers who pay down more than their fair share of legitimate tech debt are invariably the ones who complain about it the least.

thiagooffm 8y ago
It might be upvoted because people find it catchy. But if you have ever wrote code in your life, you know that person who wrote about it got no idea whatsoever about software development. I'll upvote it as well, as it is possibly the thing with the least amount of intelligence that I've read so far in my life.
fhood 8y ago
Sure, but are you differentiating between run of the mill bitching, and actual serious concerns? Because if I whine about x internal library in stand up, that is probably not important. But if I come to you in person and tell you that x internal library is introducing more bugs than saving time, I probably really mean/am concerned by that.
- Fire-Dragon-DoL 8y ago
  Freshly written code can easily be technical debt. An example of this could be "put a junior in a comolex piece of code and let him add a feature". That feature will work and probably is technical debt, because of bad design choices. I've been on the other side of this. I was developing the frontend part to a series of http endpoints and my colleague was working on the http endpoints. He was creating some terrible code but I had no power at the time. When he was done, the code was functional, had various bug and a new feature was needed. I spent a week studying the code and managed to add a feature, which however was buggy due to how the code was written originally. I fixed all the bugs, and ended up totalling 4 weeks of work. This colleague was let go after this due to a series of circumstances, so I became the owner of the code. Then a new feature needed to be added but to do that i'd need to change various things in such code. Two weeks in, I still wasn't done. At some point I asked to be able to rewrite the code. I did, it took 2 weeks and was able to add the feature easily. I'm no genius but code that cripples you down from the get-go is tech debt. Tech debt is failure in software design, which ends up in unmaintainable code. I'd listen to anyone pointing at tech debt in my code, it means my code sucks, I made a big professional mistake and I need to correct it. There is also voluntarily added tech debt, that's the one added by taking shortcuts. As long as you don't build new features on top of it, you are good.