5 ms·

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

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.
mcv 8y ago
> 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. Yeah, those things are not technical debt. But that doesn't mean that technical debt is a real issue. Technical debt isn't about whether you like or understand a particular approach, it's about whether the codebase as a whole is still maintainable, whether the bugs make sense and are fixable, whether new features can be added without stabilising the whole code base. It's never the new feature that's the problem. If the new feature can't be added in a good way, it's the old codebase that has unhandled technical debt.
- 0xdeadbeefbabe 8y ago
  Ugh. Instead of redefining common usage you could just use a different word or words. Edit: Is saying "bad design" or "ineffective design" going to lead to some fearful confrontation?
  - geezerjay 8y ago
    OP's usage and explanation of the term are spot on, and you miss the whole point if you conflate technical debt with bad design. One of the causes of technical debt is a change in requirements, and changing the initial requirements doesn't mean that the design was bad.
    - 0xdeadbeefbabe 8y ago
      Common usage misses the whole point as well.
      - geezerjay 8y ago
        Just because you personally misundertand a concept it doesn't mean everyone else is wrong.
jibal 8y ago
> 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. Oh really? I recently contracted with an industrial firm where most of the programming staff copy and paste at the drop of the hat and have no idea what DRY is, and think that technical debt and refactoring are some fancy university CS theory that "practical" programmers like them have no use for. I explained to the manager at some length the development and maintenance costs of the massive technical debt of their 30 year old code base, while at the same time I tried to reduce it a bit with every submit.
- repolfx 8y ago
  Good for you :) I think your situation sounds a bit different, where the manager either isn't very technical or isn't technical enough. Otherwise they'd be able to see the problem for themselves. What I'm talking about are employees who have managers who understand the value of refactoring. What I find is that the people who get stuck in and most unambiguously improve hairy bits of the code (with full support of management) are usually not the ones who complain loudly and publicly about tech debt. Speaking as a manager for a sec here, what I'd watch out for in your case is to not be seen too much as a complainer. Rather than say "this codebase is shit why does nobody care" look at it as, "hey guys! why not come to my interesting 10 minute lightning talk on my favourite refactoring technique" and maybe don't phrase it as about tech debt if they aren't responsive to that kind of analogy. Managers in particular probably know their codebase is shit even if they aren't very technical, but labelling things as "tech debt" is always tricky because it's entirely possible that the debt was created by colleagues or those very same managers themselves, and whilst financial debt is well defined and measurable, tech debt is just an analogy. They may not even agree that any given bit of code is a problem.
  - jibal 8y ago
    > I think your situation sounds a bit different Even if so, that's not relevant; you said that people like me "invariably" don't exist. > where the manager either isn't very technical or isn't technical enough. Otherwise they'd be able to see the problem for themselves. No, that's entirely wrong. As I clearly stated, it's the programming staff who can't see the problem. They are the people who never complain about technical debt while also never reducing it, contrary to your statement. That's the point, and your "good for you" is point-missingly dismissive. > Speaking as a manager for a sec here Just don't; I've been developing software since 1965 and I don't need your lectures (which are based on a complete lack of knowledge and erroneous assumptions about the software manager at that firm and my relationship and interactions with him), I simply pointed out that your sweeping generalization about who reduces technical debt and who points it out is erroneous. That's all. Period. The end. I won't respond further.

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.

mcv 8y ago

> 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. Yeah, those things are not technical debt. But that doesn't mean that technical debt is a real issue. Technical debt isn't about whether you like or understand a particular approach, it's about whether the codebase as a whole is still maintainable, whether the bugs make sense and are fixable, whether new features can be added without stabilising the whole code base. It's never the new feature that's the problem. If the new feature can't be added in a good way, it's the old codebase that has unhandled technical debt.

0xdeadbeefbabe 8y ago
Ugh. Instead of redefining common usage you could just use a different word or words. Edit: Is saying "bad design" or "ineffective design" going to lead to some fearful confrontation?
- geezerjay 8y ago
  OP's usage and explanation of the term are spot on, and you miss the whole point if you conflate technical debt with bad design. One of the causes of technical debt is a change in requirements, and changing the initial requirements doesn't mean that the design was bad.
  - 0xdeadbeefbabe 8y ago
    Common usage misses the whole point as well.
    - geezerjay 8y ago
      Just because you personally misundertand a concept it doesn't mean everyone else is wrong.

jibal 8y ago

> 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. Oh really? I recently contracted with an industrial firm where most of the programming staff copy and paste at the drop of the hat and have no idea what DRY is, and think that technical debt and refactoring are some fancy university CS theory that "practical" programmers like them have no use for. I explained to the manager at some length the development and maintenance costs of the massive technical debt of their 30 year old code base, while at the same time I tried to reduce it a bit with every submit.

repolfx 8y ago
Good for you :) I think your situation sounds a bit different, where the manager either isn't very technical or isn't technical enough. Otherwise they'd be able to see the problem for themselves. What I'm talking about are employees who have managers who understand the value of refactoring. What I find is that the people who get stuck in and most unambiguously improve hairy bits of the code (with full support of management) are usually not the ones who complain loudly and publicly about tech debt. Speaking as a manager for a sec here, what I'd watch out for in your case is to not be seen too much as a complainer. Rather than say "this codebase is shit why does nobody care" look at it as, "hey guys! why not come to my interesting 10 minute lightning talk on my favourite refactoring technique" and maybe don't phrase it as about tech debt if they aren't responsive to that kind of analogy. Managers in particular probably know their codebase is shit even if they aren't very technical, but labelling things as "tech debt" is always tricky because it's entirely possible that the debt was created by colleagues or those very same managers themselves, and whilst financial debt is well defined and measurable, tech debt is just an analogy. They may not even agree that any given bit of code is a problem.
- jibal 8y ago
  > I think your situation sounds a bit different Even if so, that's not relevant; you said that people like me "invariably" don't exist. > where the manager either isn't very technical or isn't technical enough. Otherwise they'd be able to see the problem for themselves. No, that's entirely wrong. As I clearly stated, it's the programming staff who can't see the problem. They are the people who never complain about technical debt while also never reducing it, contrary to your statement. That's the point, and your "good for you" is point-missingly dismissive. > Speaking as a manager for a sec here Just don't; I've been developing software since 1965 and I don't need your lectures (which are based on a complete lack of knowledge and erroneous assumptions about the software manager at that firm and my relationship and interactions with him), I simply pointed out that your sweeping generalization about who reduces technical debt and who points it out is erroneous. That's all. Period. The end. I won't respond further.