2 ms·

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 b

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...
hinkley 4y ago
> "why is this valuable" until you get to the money questions Often this is one layer too far though. Business relationships aren't 100% about business, or we wouldn't put an adjective in front of 'relationship'. We'd just call it 'business'. If you know engineers are trying to put together a proposal to take on a project that might not be immediately obvious to the business, we already know all we need to know here. Developers don't go out of their way to put together proposals for frippery, and most of them don't put together proposals for clear business cases either. They put together proposals because something is pissing them off, one way or another. If you say no, after they've stuck their necks out, then you've damaged a relationship with people who are not comfortable being clear or direct about these sorts of problems. People who you are paying to more clever than you. Which means when the consequences come, you won't see them coming, be it by apathy or malice. We aren't allowed to say, "if you don't give us time to fix some of this stuff I'm going to quit, or worse," and so everyone tries to sugar coat the real reasons with things that are objectively true but specious motivations at best. As far as I'm concerned, the original notion of tech debt was intended to be about borrowing on good will, asking people to do something they don't really want to do, but with the idea of an eventual end. That kind of sacrifice can often be quite healthy, even transformative. But what happened instead was advanced game theory. How long can we stay on the verge of social and/or technical bankruptcy without ever crossing over? And every new kind of 'check' they learn to float is a whole new world of delaying tactics. Getting a divorce is very expensive, but you don't avoid divorce because it's expensive. If you're smart, you don't even mention that it's expensive, because if you weren't having an argument before, you are certainly having one now.

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...

hinkley 4y ago

> "why is this valuable" until you get to the money questions Often this is one layer too far though. Business relationships aren't 100% about business, or we wouldn't put an adjective in front of 'relationship'. We'd just call it 'business'. If you know engineers are trying to put together a proposal to take on a project that might not be immediately obvious to the business, we already know all we need to know here. Developers don't go out of their way to put together proposals for frippery, and most of them don't put together proposals for clear business cases either. They put together proposals because something is pissing them off, one way or another. If you say no, after they've stuck their necks out, then you've damaged a relationship with people who are not comfortable being clear or direct about these sorts of problems. People who you are paying to more clever than you. Which means when the consequences come, you won't see them coming, be it by apathy or malice. We aren't allowed to say, "if you don't give us time to fix some of this stuff I'm going to quit, or worse," and so everyone tries to sugar coat the real reasons with things that are objectively true but specious motivations at best. As far as I'm concerned, the original notion of tech debt was intended to be about borrowing on good will, asking people to do something they don't really want to do, but with the idea of an eventual end. That kind of sacrifice can often be quite healthy, even transformative. But what happened instead was advanced game theory. How long can we stay on the verge of social and/or technical bankruptcy without ever crossing over? And every new kind of 'check' they learn to float is a whole new world of delaying tactics. Getting a divorce is very expensive, but you don't avoid divorce because it's expensive. If you're smart, you don't even mention that it's expensive, because if you weren't having an argument before, you are certainly having one now.