I agree that the term is overused and misused, but I don't think it's outdated.
I'm not an engineer, but for what it's worth, if anyone asks me to explain what I mean by technical debt, then I say it's the outcome of either (1) the gap that emerges when our understanding of a domain or solution evolves beyond our original implementation; or (2) the intentional, deliberate trade-offs we make to meet business goals (including to learn or validate, not just release stuff).
I'd see the idea of optionality as helping to reduce the cost of repaying technical debt (when required) under the first of those scenarios. (If you're already making trade-offs under the second scenario, you probably won't be afforded the means to buy the option.)
As you say, an option gives you the right, but not the obligation, to buy a product or good in the future at a fixed price. The problem comes when as an engineer you feel you have an obligation, but the wider business doesn't give you the right.
Thanks for your thoughtful reply, Nick. I agree with a lot of what you say.
I think the reason why I use the term outdated, even if it's slightly provocative, is that tech debt isn't very helpful when it comes to conversations with the business about the trade-offs we're making.
The key difference in the metaphor for me is the idea of optionality that options * uncertainty = value. In this sense, while the downside is capped, the upside is potentially unlimited. With tech debt, there's a capped upside (being 'debt free') that doesn't mean much to business stakeholders. The idea of increasing the value of your software, and thus by extension the wider business, by investing in software design and other helpful practices is, in my experience, much more tangible for the non-technical audience ('1 dollar today, or 10 dollars tomorrow').
"The problem comes when as an engineer you feel you have an obligation, but the wider business doesn't give you the right."
This is exactly the problem that the language of optionality helps to solve - creating alignment and having a metaphor that both sides can understand more intuitively. And as engineers, we're always making these trade-offs no matter what we do. So that's the other side of the coin of optionality for me—helping engineers understand that any decisions about software they're making have to be framed within the wider business context and can't be divorced from it.
Ultimately, we're talking about the same thing - I just think optionality helps us talk about it more effectively.
Ultimately, we're talking about the same thing - I just think optionality helps us talk about it more effectively.
Thanks for your equally thoughtful response, Alex.
A few months back I started to write about technical debt expecting to come out against it as a useful concept, but I ended up going in the opposite direction, towards what some people call 'tech debt metaphor maximalism'.
Very interesting, thanks for sharing! Reading your articles underscores to me that we really are trying to grapple with the same problem, which is to help bring engineering and the wider business closer together
You took an unexpected turn for me. I thought you'd talk about how incurring tech debt is an option, and then I read a post about how we need to design for optionality.
Did I miss something? Tech Debt may, or not, remove optionality, but it provides (sometimes) a way to get a certain return (to market first, no need to hire expensive consultants, etc.).
So, now I'm left with the question: how would you frame optionality related to tech debt instead of architecture?
Great question! I actually recorded a live where I attempted to answer this :) I’ll share the recording once it’s published and you can be the judge of whether I succeeded
I agree that the term is overused and misused, but I don't think it's outdated.
I'm not an engineer, but for what it's worth, if anyone asks me to explain what I mean by technical debt, then I say it's the outcome of either (1) the gap that emerges when our understanding of a domain or solution evolves beyond our original implementation; or (2) the intentional, deliberate trade-offs we make to meet business goals (including to learn or validate, not just release stuff).
I'd see the idea of optionality as helping to reduce the cost of repaying technical debt (when required) under the first of those scenarios. (If you're already making trade-offs under the second scenario, you probably won't be afforded the means to buy the option.)
As you say, an option gives you the right, but not the obligation, to buy a product or good in the future at a fixed price. The problem comes when as an engineer you feel you have an obligation, but the wider business doesn't give you the right.
Thanks for your thoughtful reply, Nick. I agree with a lot of what you say.
I think the reason why I use the term outdated, even if it's slightly provocative, is that tech debt isn't very helpful when it comes to conversations with the business about the trade-offs we're making.
The key difference in the metaphor for me is the idea of optionality that options * uncertainty = value. In this sense, while the downside is capped, the upside is potentially unlimited. With tech debt, there's a capped upside (being 'debt free') that doesn't mean much to business stakeholders. The idea of increasing the value of your software, and thus by extension the wider business, by investing in software design and other helpful practices is, in my experience, much more tangible for the non-technical audience ('1 dollar today, or 10 dollars tomorrow').
"The problem comes when as an engineer you feel you have an obligation, but the wider business doesn't give you the right."
This is exactly the problem that the language of optionality helps to solve - creating alignment and having a metaphor that both sides can understand more intuitively. And as engineers, we're always making these trade-offs no matter what we do. So that's the other side of the coin of optionality for me—helping engineers understand that any decisions about software they're making have to be framed within the wider business context and can't be divorced from it.
Ultimately, we're talking about the same thing - I just think optionality helps us talk about it more effectively.
Ultimately, we're talking about the same thing - I just think optionality helps us talk about it more effectively.
Thanks for your equally thoughtful response, Alex.
A few months back I started to write about technical debt expecting to come out against it as a useful concept, but I ended up going in the opposite direction, towards what some people call 'tech debt metaphor maximalism'.
https://adjacentangles.substack.com/p/think-of-tech-debt-like-a-zero-coupon?r=2nacy9
https://adjacentangles.substack.com/p/life-of-the-counterparty-tech-debt?r=2nacy9
It's an interesting area, and likely a source of debate and tension for a long time to come.
Very interesting, thanks for sharing! Reading your articles underscores to me that we really are trying to grapple with the same problem, which is to help bring engineering and the wider business closer together
You took an unexpected turn for me. I thought you'd talk about how incurring tech debt is an option, and then I read a post about how we need to design for optionality.
Did I miss something? Tech Debt may, or not, remove optionality, but it provides (sometimes) a way to get a certain return (to market first, no need to hire expensive consultants, etc.).
So, now I'm left with the question: how would you frame optionality related to tech debt instead of architecture?
Great question! I actually recorded a live where I attempted to answer this :) I’ll share the recording once it’s published and you can be the judge of whether I succeeded
Oh this piece is so timely!