3 ms·

>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poo

>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. It's absolutely not that. Technical debt is a natural by-product of working even with the best coders. There's nobody out there who doesn't create it. Better coders just produce it more slowly and clean it up more often. >I'm not sure I ever found myself in the position of writing bad code just for the sake of speed I could literally spend all of my time making code nicer and none at all developing features/fixing bugs. It's always a trade off between speed and quality.

Udik 10y ago
Of course. Some developers (or product owners, architects, managers) generate technical debt slower, some other generate it faster. Some generate a substantial amount of it for a task in which others would generate very little - in the same time frame. Then why don't we call it lack of skills? Sounds the same to me.
- crdoconnor 10y ago
  Because the same developer with the same skills can often ramp up technical debt to get a feature out in half an hour instead of a day, and there aren't any developers who haven't felt the pressure to do exactly that. Ramping up technical debt isn't always about speed, either. It's sometimes about risk - it's often less risky in the short term to copy and paste a block of code than it is to change a block of code and risk breaking something else.
  - Udik 10y ago
    True. The amount of technical debt produced is a function of the time constraints and the person skills. In turn, the time constraints can depend on the skills of other people in the organization at planning, designing, figuring out requirements, managing the team and the process, etc. Saying "ah sorry, we'll have to work one more week/ month on this because, you know, technical debt" is sweeping all these possible issues under one big carpet.
    - crdoconnor 10y ago
      I don't see why. Technical debt is just a measure of how much crap there is in the code. It doesn't preclude having a discussion about how much that is to do with skills and how much that is to do with pressure/time constraints/existing technical debt. The point of the dial is just to make the trade off between quality and speed that individual developers are making every day both explicit and management's responsibility. It means if the dial is turned up to 100% management have no excuse for asking the question "why is our product a pile of crap?". It means also if the dial was at 60% for a year and a half the developers have no excuse for why the product is still riddled in technical debt, meaning that skills problems are distinguished from time constraints and managerial pressure comes with a cost attached.

Udik 10y ago

Of course. Some developers (or product owners, architects, managers) generate technical debt slower, some other generate it faster. Some generate a substantial amount of it for a task in which others would generate very little - in the same time frame. Then why don't we call it lack of skills? Sounds the same to me.

crdoconnor 10y ago
Because the same developer with the same skills can often ramp up technical debt to get a feature out in half an hour instead of a day, and there aren't any developers who haven't felt the pressure to do exactly that. Ramping up technical debt isn't always about speed, either. It's sometimes about risk - it's often less risky in the short term to copy and paste a block of code than it is to change a block of code and risk breaking something else.
- Udik 10y ago
  True. The amount of technical debt produced is a function of the time constraints and the person skills. In turn, the time constraints can depend on the skills of other people in the organization at planning, designing, figuring out requirements, managing the team and the process, etc. Saying "ah sorry, we'll have to work one more week/ month on this because, you know, technical debt" is sweeping all these possible issues under one big carpet.
  - crdoconnor 10y ago
    I don't see why. Technical debt is just a measure of how much crap there is in the code. It doesn't preclude having a discussion about how much that is to do with skills and how much that is to do with pressure/time constraints/existing technical debt. The point of the dial is just to make the trade off between quality and speed that individual developers are making every day both explicit and management's responsibility. It means if the dial is turned up to 100% management have no excuse for asking the question "why is our product a pile of crap?". It means also if the dial was at 60% for a year and a half the developers have no excuse for why the product is still riddled in technical debt, meaning that skills problems are distinguished from time constraints and managerial pressure comes with a cost attached.