4 ms·

I distrust my fellow software engineers when they say they need time to pay tech debt. There were many times where I refactored code that never received any ad

I distrust my fellow software engineers when they say they need time to pay tech debt. There were many times where I refactored code that never received any additional updates or to have the feature removed. I wasted a lot of time without any real gain for it. There are real costs to paying off tech debt and it is easy for engineers to spend their time on low value refactoring. Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there. If you can show you can prioritize business value then it is easier to convince management to give you two weeks to clean up tech debt.

missosoup 7y ago
> If you can show you can prioritize business value then it is easier to convince management If your management needs 'convincing' then there's a problem. Either the manager is technical enough to know whether a particular set of work is the right thing to do or not, in which case they don't need convincing. Or they're not, in which case they should defer to the engineer and also not need convincing. The only managers who need 'convincing' on technical matters are technically inept individuals who nonetheless attempt to micromanage technical decision making. They are no more able to link business value to technical decisions than the engineers you say you distrust. Fire them.
- killbot5000 7y ago
  > Engineers don't generally enjoy paying off technical debt, it's a chore. But they recognise that it must be done sometimes. I disagree. Most engineers I work with like refactoring. It’s usually well defined work with clear metrics for success. It can also reduce daily pain if it makes delicate/messy code much easier to work with. The problem with refactoring is that its only value is in improved execution of future projects. So it can be extremely valuable or completely useless. It depends on how likely the refactored things are to be worked on again.
rumanator 7y ago
> Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there. This. Software engineers are focused on the implementation side of things and how today's work will impact their work in the future. Yet, sometimes a quick and dirty solution that takes close to nothing to implement is more than enough to put a functionality in production. Sure, the whole thing will need to be scrapped in the near future when rewriting the feature to meet all design requirements, naturally the quick and dirty solution underperforms, and of course implementing it properly will take 3 or 5x the time. Isn't it obvious that the team is wasting it's time by implementing a quick and dirty solution? Yet, the quick and dirty feature does shorten the time to market to a fraction of what it would otherwise take to implement properly, and perhaps that is good enough for the project for the time being.
- pytester 7y ago
  It's for this reason that I've often tried to get the business side to give opinions on how shoddy/quickly they'd like the feature to be done. Curiously a lot of the time they appear very reluctant to do so. It's probably CYA kicking in maybe... many managers don't like to say "do a shoddy job" if it ends up biting them in the ass later... they'd often rather just hint and exert unspoken pressure to rush it out and then deny everything later when the CEO starts asking questions a bug that fucked everything up. There are exceptions, of course, and I'm pretty happy to have worked with them, but in general about 90% of managers I've worked with have resisted my attempts to get them to be explicit about the level of quality that they want.
  - Normal_gaussian 7y ago
    Quality is so ridiculously subjective that I'm not sure a non-technical manager should approach the question, and a technical manager should refuse a direct answer and steer the conversation towards structure and deliverables.
    - pytester 7y ago
      % of time spent on refactoring is completely objective. Whether that results in quality is another matter, but it's a dial that a product manager has control over that (usually) has direct impact on the quality of the end product.
stouset 7y ago
> There were many times where I refactored code that never received any additional updates or to have the feature removed. Since we're throwing out anecdotes, I've lost count of the number of companies I've seen that were essentially zombies due to technical debt. They had aging, rotting codebases that were impossible to add features to at the rate needed to continue making sales. No senior engineers who could improve the situation wanted to set their careers back by working for them.
- hliyan 7y ago
  I think you and grandparent post's author are both right. I've seen both. It depends on the type of engineers that inhabit your team, and therefore are not mutually exclusive.
- username90 7y ago
  The main problem is that many developers will increase technical debt when they try to fix it. For example, some will try to fix technical debt by writing a new framework. Then the new framework doesn't handle all edge cases, so you still need the old solution. Now you have two different conflicting styles creating more technical debt. The next developer will come in, see the mess, and promptly start working on a framework to consolidate everything... So whenever you consider fixing technical debt, ask yourself if the team is skilled enough to actually create a cleaner solution. If they can't then it is just a waste of time. The best predictor of this is that they have created a cleaner solution elsewhere, if they haven't then don't let them work on technical debt unless they have an extremely well thought out plan.
- pytester 7y ago
  Management's solution is often to hire more software engineers. Ironically in big corporations I think that this actually plays into their underlying desires - giving a boost to headcount gives them more importance and having more developers means that the leverage each engineer has is commensurately less. I've worked on more than a few projects which would have proceeded 4x faster with 2 good developers on a clean code base than the 7 they actually had. Indeed the entire software startup industry is probably reliant upon this dynamic.
felixyz 7y ago
"Continuous attention to technical excellence and good design enhances agility." Very few people seem to actually believe this in their bones. All talk about being "agile" and "pragmatic" becomes a joke when it's posed as somehow being in contradiction to design and anything that goes deeper than finding a place to insert your new if statement.

missosoup 7y ago

> If you can show you can prioritize business value then it is easier to convince management If your management needs 'convincing' then there's a problem. Either the manager is technical enough to know whether a particular set of work is the right thing to do or not, in which case they don't need convincing. Or they're not, in which case they should defer to the engineer and also not need convincing. The only managers who need 'convincing' on technical matters are technically inept individuals who nonetheless attempt to micromanage technical decision making. They are no more able to link business value to technical decisions than the engineers you say you distrust. Fire them.

killbot5000 7y ago
> Engineers don't generally enjoy paying off technical debt, it's a chore. But they recognise that it must be done sometimes. I disagree. Most engineers I work with like refactoring. It’s usually well defined work with clear metrics for success. It can also reduce daily pain if it makes delicate/messy code much easier to work with. The problem with refactoring is that its only value is in improved execution of future projects. So it can be extremely valuable or completely useless. It depends on how likely the refactored things are to be worked on again.

rumanator 7y ago

> Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there. This. Software engineers are focused on the implementation side of things and how today's work will impact their work in the future. Yet, sometimes a quick and dirty solution that takes close to nothing to implement is more than enough to put a functionality in production. Sure, the whole thing will need to be scrapped in the near future when rewriting the feature to meet all design requirements, naturally the quick and dirty solution underperforms, and of course implementing it properly will take 3 or 5x the time. Isn't it obvious that the team is wasting it's time by implementing a quick and dirty solution? Yet, the quick and dirty feature does shorten the time to market to a fraction of what it would otherwise take to implement properly, and perhaps that is good enough for the project for the time being.

pytester 7y ago
It's for this reason that I've often tried to get the business side to give opinions on how shoddy/quickly they'd like the feature to be done. Curiously a lot of the time they appear very reluctant to do so. It's probably CYA kicking in maybe... many managers don't like to say "do a shoddy job" if it ends up biting them in the ass later... they'd often rather just hint and exert unspoken pressure to rush it out and then deny everything later when the CEO starts asking questions a bug that fucked everything up. There are exceptions, of course, and I'm pretty happy to have worked with them, but in general about 90% of managers I've worked with have resisted my attempts to get them to be explicit about the level of quality that they want.
- Normal_gaussian 7y ago
  Quality is so ridiculously subjective that I'm not sure a non-technical manager should approach the question, and a technical manager should refuse a direct answer and steer the conversation towards structure and deliverables.
  - pytester 7y ago
    % of time spent on refactoring is completely objective. Whether that results in quality is another matter, but it's a dial that a product manager has control over that (usually) has direct impact on the quality of the end product.

stouset 7y ago

> There were many times where I refactored code that never received any additional updates or to have the feature removed. Since we're throwing out anecdotes, I've lost count of the number of companies I've seen that were essentially zombies due to technical debt. They had aging, rotting codebases that were impossible to add features to at the rate needed to continue making sales. No senior engineers who could improve the situation wanted to set their careers back by working for them.

hliyan 7y ago
I think you and grandparent post's author are both right. I've seen both. It depends on the type of engineers that inhabit your team, and therefore are not mutually exclusive.
username90 7y ago
The main problem is that many developers will increase technical debt when they try to fix it. For example, some will try to fix technical debt by writing a new framework. Then the new framework doesn't handle all edge cases, so you still need the old solution. Now you have two different conflicting styles creating more technical debt. The next developer will come in, see the mess, and promptly start working on a framework to consolidate everything... So whenever you consider fixing technical debt, ask yourself if the team is skilled enough to actually create a cleaner solution. If they can't then it is just a waste of time. The best predictor of this is that they have created a cleaner solution elsewhere, if they haven't then don't let them work on technical debt unless they have an extremely well thought out plan.
pytester 7y ago
Management's solution is often to hire more software engineers. Ironically in big corporations I think that this actually plays into their underlying desires - giving a boost to headcount gives them more importance and having more developers means that the leverage each engineer has is commensurately less. I've worked on more than a few projects which would have proceeded 4x faster with 2 good developers on a clean code base than the 7 they actually had. Indeed the entire software startup industry is probably reliant upon this dynamic.

felixyz 7y ago

"Continuous attention to technical excellence and good design enhances agility." Very few people seem to actually believe this in their bones. All talk about being "agile" and "pragmatic" becomes a joke when it's posed as somehow being in contradiction to design and anything that goes deeper than finding a place to insert your new if statement.