3 ms·

OP here. We had a lot of discussion about where Tech Debt falls on the spectrum of projects to work on. That merits its own post. But the gist of it is that res

OP here. We had a lot of discussion about where Tech Debt falls on the spectrum of projects to work on. That merits its own post. But the gist of it is that resolving tech debt has value. The challenge is that most engineering organizations are awful at describing and communicating that value. For example: "If we refactor this code and migrate to a new server, we'll be able to deploy in 15 minutes instead of 6 hours, and we'll be able to ship features faster to customers with lower risk. This means that we'll get back ~90h of engineering time per week (6 hours x 5 people x 3 teams), and our defect rate will go down by 50% (We see 10% of customers churn due to preventable defects).. Therefore, there is $702,000 savings in engineering efficiency (more time available) and would decrease churn by 10%, resulting in [X] more value retained." Once our engineering team started thinking about the business case for why tech debt should be prioritized, they started to make really compelling arguments for why something needed to be worked on, and we could evaluate it against explicit business/feature requests. This value rolled up into the form of decreasing costs or increasing revenue. Again: resolving tech debt has value, and the engineering leadership needs to work on figuring out what that value is and how it stacks up against all of the other valuable work that the company wants to do to grow. Engineering leaders who don't understand this often struggle at the executive level and ultimately fail the teams they represent.

yen223 4y ago
The problem I think is engineering haven't figured out good ways to measure software productivity, and so it's very hard to make the kinds of estimates that we need to properly justify work that otherwise delivers zero immediate business value. (I also suspect that not all refactoring work is equal, and that most refactoring work don't result in any positive engineering or business improvements.)
- babyshake 4y ago
  Easy, you just measure the lines of code added. More code means more productive.
  - Thiez 4y ago
    The one checking in the node_modules folder is the most productive developer?
- goopthink 4y ago
  This is very fair! We used a few guide posts: - 1: Keep asking "why is this valuable" until you get to the money questions. It's often a few layers deep. Not being able to get at that (missing an ability to quantify) was in itself something that engineering leadership needed to work on. After all -- how can you prioritize between two things if you can't figure out what value they create? - 2: Most engineering teams know that they might be able to save some time by refactoring. We figured out the average hourly cost of engineering effort and used that as a multiplier for time saved by a new project's implementation. You can take it a step further and subtract the cost of working on a project from the time it ultimately saves you to remove "dumb" refactors that take longer to deliver than time they save. - 3: If you can't get to a tech debt's value, that's a red flag as to if it actually creates value. This was true for features and business requests as well. We also said no to features that "felt good" but ultimately created zero value (some redesigns included). "Rewriting something in a new language" because a new sr manager with strong preferences joined the team was a big culprit of these sorts of projects. - 4: We also often asked if a tech debt project needed to be done independently of other work, or if it could be included as part of a new feature that we were working on. An example was that one team pitched rewriting a microservice because it had no API. On the other side of the company, we had a project to get rid of that feature entirely and replace it with a different functionality. If tech debt projects were handled entirely within the domain of engineering, we would have spent weeks rewriting something only to throw it away a month later. Hence the need for bubbling tech debt up to the single stack rank, and thus treating tech debt projects the same as any other project we were working on (with appropriate visibility, buy-in, and evaluation of value/urgency).
  - RugnirViking 4y ago
    Reading these comments and replies has me very interested. I think talking about technical debts and ways of quantifying it is definitely worth another post. I'd read it!
    - ianmcgowan 4y ago
      You might find "The principles of product development flow" interesting. A large component of the book is about quantifying all work to be done, and then managing the resulting queues and WIP. Many aspects of the article reminded me of this book, but with concrete implementations of general techniques, which was very helpful. [1] https://www.thriftbooks.com/w/the-principles-of-product-development-flow-second-generation-lean-product-development_donald-g-reinertsen/453321/item/4779118/?gclid=CjwKCAjw4ayUBhA4EiwATWyBrl5CM-S0FgMvR4bcMoLc5eL6br3vC6cA5ZLs51Fpw1mHtNEhv0Vr-hoCkYgQAvD_BwE#idiq=4779118&edition=5935514 https://www.thriftbooks.com/w/the-principles-of-product-deve...
- magicalhippo 4y ago
  > I also suspect that not all refactoring work is equal, and that most refactoring work don't result in any positive engineering or business improvements. We have lots of old code in production, some 25 years old. Much of it written during the startup crunch, with little thought to extensibility and so on. But it works. So we have a rule to only cleanup/refactor code when we have a specific case which requires us to change it. If it requires a bit more than a minor change, we'll do a cleanup, refactor or rewrite depending on the circumstance.
  - laserlight 4y ago
    Remove-tech-debt-as-you-go is how I approach the problem. Doing so ensures that removing tech debt is not done in a vacuum, disconnected from business needs.
cgio 4y ago
Once the engineering team started thinking about business cases, they started wasting time they could be dedicating to engineering. I know where you come from, on a similar journey, but when things don’t work, adding things to do is the worst option.
- goopthink 4y ago
  I'm not sure I agree. There's two key elements: 1. If you don't properly evaluate the work and be selective with what you work on, actual engineering time will be allocated to too many projects. People spin their wheels working on potentially insignificant things, which is a morale killer. So thinking about the business cases was a way of reducing work, not adding work. 2. I tried to emphasize that thinking about business cases is something product and engineering management/leadership need to own, not necessarily IC engineers. ICs can add ideas to the backlog and identify opportunity, and it is the job of PMs and EMs to evaluate those ideas and sequence them for being worked on, relative to other projects. The feedback loop that is important to ICs is the impact of their work in terms of user metrics and goals the project was supposed to accomplish. I don't want to get too heartfelt about it (because Capitalism, Yay!), but there's a difference between churning out features into a black hole and knowing how your deliverables affect the people for whom you build things, and letting that continue to inform your work.
  - cgio 4y ago
    I think we are more aligned than what our exchange may superficially imply. But to clarify, from a value generation perspective, I don’t see tech debt as something whose payoff would generate any value other than in terms of technical flexibility and long term engineering resources availability. If a tech debt item is adding a feature then it’s not tech debt. Tech debt is born out of suboptimal support for features. So the feature is in place, but not in the proper technical way (I.e. against target architecture, held together with manual processes etc.). As such my approach with tech debt is realise the value by having cadence of paying tech debt off, not being afraid or thinking too much about the value of bringing things up to date. It’s more of a keep the engine running approach, at least in big engineering organisations where that makes sense from financial perspective as they resemble more a locomotive than a car in economics of restarting vs running ongoing. I am also confident both approaches may equally work or fail depending on organisation dynamics.
inglor_cz 4y ago
My software work is centered around security and I find it almost impossible to persuade managers that security is worth anything. The exception is when a major hacking event unfolds in the media. Then, suddenly everyone is attentive. I suspect it is the same with militaries, except the USA and a few other countries. It is easy for politicians to cut military budgets and spend the money on civilians, and some intellectuals will even praise them as prioritizing peace, until suddenly tanks adorned with white letters roll over Ukrainian borders. Then, countries panic because their underfinanced military force is inadequate to the threat, which just became very real. (I am looking at you, Germany.)

yen223 4y ago

The problem I think is engineering haven't figured out good ways to measure software productivity, and so it's very hard to make the kinds of estimates that we need to properly justify work that otherwise delivers zero immediate business value. (I also suspect that not all refactoring work is equal, and that most refactoring work don't result in any positive engineering or business improvements.)

babyshake 4y ago
Easy, you just measure the lines of code added. More code means more productive.
- Thiez 4y ago
  The one checking in the node_modules folder is the most productive developer?
goopthink 4y ago
This is very fair! We used a few guide posts: - 1: Keep asking "why is this valuable" until you get to the money questions. It's often a few layers deep. Not being able to get at that (missing an ability to quantify) was in itself something that engineering leadership needed to work on. After all -- how can you prioritize between two things if you can't figure out what value they create? - 2: Most engineering teams know that they might be able to save some time by refactoring. We figured out the average hourly cost of engineering effort and used that as a multiplier for time saved by a new project's implementation. You can take it a step further and subtract the cost of working on a project from the time it ultimately saves you to remove "dumb" refactors that take longer to deliver than time they save. - 3: If you can't get to a tech debt's value, that's a red flag as to if it actually creates value. This was true for features and business requests as well. We also said no to features that "felt good" but ultimately created zero value (some redesigns included). "Rewriting something in a new language" because a new sr manager with strong preferences joined the team was a big culprit of these sorts of projects. - 4: We also often asked if a tech debt project needed to be done independently of other work, or if it could be included as part of a new feature that we were working on. An example was that one team pitched rewriting a microservice because it had no API. On the other side of the company, we had a project to get rid of that feature entirely and replace it with a different functionality. If tech debt projects were handled entirely within the domain of engineering, we would have spent weeks rewriting something only to throw it away a month later. Hence the need for bubbling tech debt up to the single stack rank, and thus treating tech debt projects the same as any other project we were working on (with appropriate visibility, buy-in, and evaluation of value/urgency).
- RugnirViking 4y ago
  Reading these comments and replies has me very interested. I think talking about technical debts and ways of quantifying it is definitely worth another post. I'd read it!
  - ianmcgowan 4y ago
    You might find "The principles of product development flow" interesting. A large component of the book is about quantifying all work to be done, and then managing the resulting queues and WIP. Many aspects of the article reminded me of this book, but with concrete implementations of general techniques, which was very helpful. [1] https://www.thriftbooks.com/w/the-principles-of-product-development-flow-second-generation-lean-product-development_donald-g-reinertsen/453321/item/4779118/?gclid=CjwKCAjw4ayUBhA4EiwATWyBrl5CM-S0FgMvR4bcMoLc5eL6br3vC6cA5ZLs51Fpw1mHtNEhv0Vr-hoCkYgQAvD_BwE#idiq=4779118&edition=5935514 https://www.thriftbooks.com/w/the-principles-of-product-deve...
magicalhippo 4y ago
> I also suspect that not all refactoring work is equal, and that most refactoring work don't result in any positive engineering or business improvements. We have lots of old code in production, some 25 years old. Much of it written during the startup crunch, with little thought to extensibility and so on. But it works. So we have a rule to only cleanup/refactor code when we have a specific case which requires us to change it. If it requires a bit more than a minor change, we'll do a cleanup, refactor or rewrite depending on the circumstance.
- laserlight 4y ago
  Remove-tech-debt-as-you-go is how I approach the problem. Doing so ensures that removing tech debt is not done in a vacuum, disconnected from business needs.

cgio 4y ago

Once the engineering team started thinking about business cases, they started wasting time they could be dedicating to engineering. I know where you come from, on a similar journey, but when things don’t work, adding things to do is the worst option.

goopthink 4y ago
I'm not sure I agree. There's two key elements: 1. If you don't properly evaluate the work and be selective with what you work on, actual engineering time will be allocated to too many projects. People spin their wheels working on potentially insignificant things, which is a morale killer. So thinking about the business cases was a way of reducing work, not adding work. 2. I tried to emphasize that thinking about business cases is something product and engineering management/leadership need to own, not necessarily IC engineers. ICs can add ideas to the backlog and identify opportunity, and it is the job of PMs and EMs to evaluate those ideas and sequence them for being worked on, relative to other projects. The feedback loop that is important to ICs is the impact of their work in terms of user metrics and goals the project was supposed to accomplish. I don't want to get too heartfelt about it (because Capitalism, Yay!), but there's a difference between churning out features into a black hole and knowing how your deliverables affect the people for whom you build things, and letting that continue to inform your work.
- cgio 4y ago
  I think we are more aligned than what our exchange may superficially imply. But to clarify, from a value generation perspective, I don’t see tech debt as something whose payoff would generate any value other than in terms of technical flexibility and long term engineering resources availability. If a tech debt item is adding a feature then it’s not tech debt. Tech debt is born out of suboptimal support for features. So the feature is in place, but not in the proper technical way (I.e. against target architecture, held together with manual processes etc.). As such my approach with tech debt is realise the value by having cadence of paying tech debt off, not being afraid or thinking too much about the value of bringing things up to date. It’s more of a keep the engine running approach, at least in big engineering organisations where that makes sense from financial perspective as they resemble more a locomotive than a car in economics of restarting vs running ongoing. I am also confident both approaches may equally work or fail depending on organisation dynamics.

inglor_cz 4y ago

My software work is centered around security and I find it almost impossible to persuade managers that security is worth anything. The exception is when a major hacking event unfolds in the media. Then, suddenly everyone is attentive. I suspect it is the same with militaries, except the USA and a few other countries. It is easy for politicians to cut military budgets and spend the money on civilians, and some intellectuals will even praise them as prioritizing peace, until suddenly tanks adorned with white letters roll over Ukrainian borders. Then, countries panic because their underfinanced military force is inadequate to the threat, which just became very real. (I am looking at you, Germany.)