Stop Saying "Technical Debt"(stackoverflow.blog)
stackoverflow.blog
Stop Saying "Technical Debt"
https://stackoverflow.blog/2023/12/27/stop-saying-technical-debt/
19 comments
Well referenced. Stop saying Stop saying “technical debt”.
If you know what kind of bad code you're talking about be specific. If someone is saying "tech debt" to refer to merely bad code, know that's a thing too and just get on with it. Don't get sidetracked debating terminology.
If you know what kind of bad code you're talking about be specific. If someone is saying "tech debt" to refer to merely bad code, know that's a thing too and just get on with it. Don't get sidetracked debating terminology.
Roy Fielding has entered the chat.
https://en.m.wikipedia.org/wiki/Representational_state_trans...
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
https://en.m.wikipedia.org/wiki/Representational_state_trans...
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
How long until we get the post 'Stop Saying "Technical Debt", Considered Harmful'?
Whenever I join an organization and hear them talk about technical debt, it raises alot of redflags, why ?.
1. because that proves inefficiency, and we hide behind technical debt.
2. because technical debt is politics and a good answer to what are you working on micro-management style.
3. because it is not pragramtic and it is very subjective.
4. because it is a joker card to play whenever you don't have a reason to justify.
We have no idea how to even get the business to consider that.
Explain to them that the depreciation/amortization rates are higher due to a lower initial capital expenditure.
Also, encourage your management to engage in Activity Based Costing instead of throwing darts at a wall.
Explain to them that the depreciation/amortization rates are higher due to a lower initial capital expenditure.
Also, encourage your management to engage in Activity Based Costing instead of throwing darts at a wall.
Exactly the discussions I have in my firm as the financially responsible. We spend loads on run, change, manage the profolio agile (not even snarking on that, I’m pretty amazed at the delivery and how much of the delivery is adequately estimated well in advance). However… I as a financial have no clue how to do run/change and TCO and ABC consistently. We do ABC as the finance organization, but it lacks the TCO and run/change insights needed to help steer IT delivery. And obviously the managers whom IT spend mostly benefits are reluctant to show the benefits directly since hey, finance is all about cutting staff right? Time tracking is an organizational no go both culturally and historically. So how can we help bring those perspectives better into view but with a light hand? Any ideas much obliged.
My dad professed managerial accounting and finance for most of his career. We’ve been talking about this a lot as it applies to the software industry and he offered too broad approaches: make ABC an almost daily routine, or a much easier approach, do periodic internal audits that get on the factory floor to actually see how engineers, product managers, EMs, etc, etc, spend their time during the day.
My email address is my username at gmail and if you would be so obliged I would love to talk to you about this more!
My email address is my username at gmail and if you would be so obliged I would love to talk to you about this more!
I mean, I could talk about this subject for awhile, but I would give EMs another task: do accounting and not just wrangling of the nerd herd.
I consider myself a veteran of the nerd herd and take pride in such a label, even the wrangling, as it is generally an attempt to guide productive, creative and engaged engineers.
I’ve also noticed a parallel between what’s called domain-driven design and ABC, namely, they are primarily concerned with a full understanding of the processes, events and activities. Agile has some tangential relationships as well and could possibly be used for the daily/weekly practice of ABC, but the problem with story points is that they also fail to capture the full costs!
I’m just rambling and spitballing at this point as I’m currently at the stage where I’m noticing something and just tracking down clues!
Hence, let’s have a call about this and brainstorm! I’m serious, I would enjoy it immensely!
I consider myself a veteran of the nerd herd and take pride in such a label, even the wrangling, as it is generally an attempt to guide productive, creative and engaged engineers.
I’ve also noticed a parallel between what’s called domain-driven design and ABC, namely, they are primarily concerned with a full understanding of the processes, events and activities. Agile has some tangential relationships as well and could possibly be used for the daily/weekly practice of ABC, but the problem with story points is that they also fail to capture the full costs!
I’m just rambling and spitballing at this point as I’m currently at the stage where I’m noticing something and just tracking down clues!
Hence, let’s have a call about this and brainstorm! I’m serious, I would enjoy it immensely!
I will send you an email next week! Thanks a lot for reaching out and your enthusiasm.
The part about making EMs responsible for the financial investment or at least some inkling of the cost/benefit part of change budget has been one we've started upon a few months back. I think that can be a rewarding trajectory, but to be honest - there is a chasm between the easy with which management controllers (my team) think about these things and boots on the ground type of work of keeping our delivery teams of say 10 programmers each working and communicating. I've learned that you shouldn't burden people managers with too much finance. Just like you shouldn't make people managers of finance people. (This somewhat in jest. We do geek out many levels of financial 'theory' above the rest of the people in regular departments. They talk sales growth, we talk the interest rates effect on return on capital invested.) I have a fear that piling finance on top of the people and systems responsibilities of the EM will not work out. At least the controllers should make it _easy_.
The part about making EMs responsible for the financial investment or at least some inkling of the cost/benefit part of change budget has been one we've started upon a few months back. I think that can be a rewarding trajectory, but to be honest - there is a chasm between the easy with which management controllers (my team) think about these things and boots on the ground type of work of keeping our delivery teams of say 10 programmers each working and communicating. I've learned that you shouldn't burden people managers with too much finance. Just like you shouldn't make people managers of finance people. (This somewhat in jest. We do geek out many levels of financial 'theory' above the rest of the people in regular departments. They talk sales growth, we talk the interest rates effect on return on capital invested.) I have a fear that piling finance on top of the people and systems responsibilities of the EM will not work out. At least the controllers should make it _easy_.
> Everybody associates the term with a feeling—frustration, usually—but they don’t have a precise idea of where that feeling comes from.
The majority of the time that I hear people using the term, they aren't expressing a feeling, they're expressing "necessary work that has been postponed".
The majority of the time that I hear people using the term, they aren't expressing a feeling, they're expressing "necessary work that has been postponed".
Totally agree that it has lost its meaning. We call things “incomplete work” that are, well, incomplete work.
I wrote more about it here: https://github.com/aaronjensen/software-development/blob/mas...
Also the advice in the article about noticing the issues and tracing them to their root is spot on. We record setbacks and mistakes in our work logs for our team to see and socialize common problems so we can address them holistically.
I wrote more about it here: https://github.com/aaronjensen/software-development/blob/mas...
Also the advice in the article about noticing the issues and tracing them to their root is spot on. We record setbacks and mistakes in our work logs for our team to see and socialize common problems so we can address them holistically.
The future proofing of a codebase from the article is IMHO wrong. This is another form of tech debt as you'll get it wrong almost all the time and it will generate dead code or arcane hacks to make it fit for the actual reality.
The way to proceed here is to fix the architecture when you spot a discrepancy between the current architecture and the current feature you are trying to implement (not more, not less). The cost is low at that point, later when a dozen features get added in the same manner the cost to fix it becomes too high to swallow.
The way to proceed here is to fix the architecture when you spot a discrepancy between the current architecture and the current feature you are trying to implement (not more, not less). The cost is low at that point, later when a dozen features get added in the same manner the cost to fix it becomes too high to swallow.
I agree that the term Technical Debt should no longer be used.
The problem is that, while the term "debt" can be understood as having consequences, there is no way to accurately measure the "interest" or "depreciation" on technical solutions. And if I can't measure these things then I can't effectively make decisions.
Interest is measured as "annual cost of borrowing" and you can see the interest payments on the bottom line. How does one define an "interest rate" on a technical decision made at design time? How can one make management see the cost of a specific decision in terms of dollars? I say you can't.
Depreciation is also measurable as the "consumption of useful value over time". Sure, depreciation is a mostly made-up thing (e.g. the lifetime of a "durable good" is 10 years, after which its value is zero), but it's something that one can reason on in terms of dollars. How does one measure depreciation of a software product encumbered by technical debt? Again, I say you can't.
Technical Debt was an interesting attempt by engineers to speak finance to management and finance people, but it never really quite fit. It's time to drop the term and find something else.
The problem is that, while the term "debt" can be understood as having consequences, there is no way to accurately measure the "interest" or "depreciation" on technical solutions. And if I can't measure these things then I can't effectively make decisions.
Interest is measured as "annual cost of borrowing" and you can see the interest payments on the bottom line. How does one define an "interest rate" on a technical decision made at design time? How can one make management see the cost of a specific decision in terms of dollars? I say you can't.
Depreciation is also measurable as the "consumption of useful value over time". Sure, depreciation is a mostly made-up thing (e.g. the lifetime of a "durable good" is 10 years, after which its value is zero), but it's something that one can reason on in terms of dollars. How does one measure depreciation of a software product encumbered by technical debt? Again, I say you can't.
Technical Debt was an interesting attempt by engineers to speak finance to management and finance people, but it never really quite fit. It's time to drop the term and find something else.
Everyone who says "<insert any phrase uttered in bizness>" assumes they know what we’re all talking about, but their individual definitions differ quite a bit.
In the words of a former president - It depends on what the meaning of the word 'is' is.
In the words of a former president - It depends on what the meaning of the word 'is' is.
There is software that is profitable, and there is software that isn't. That's all I care about. The best developers think like biz people.
Software with "technical debt" that makes $millions is highly valuable. Software with no "technical debt" not making $ is sunk cost.
Assuming you are a pro and not a hobby/OSS developer of course.
Software with "technical debt" that makes $millions is highly valuable. Software with no "technical debt" not making $ is sunk cost.
Assuming you are a pro and not a hobby/OSS developer of course.
A bit like “XYZ considered harmful”. Sounds so awkward to me but people seem to love it
Instead, start using the terms depreciation, amortization, capitalization and especially managerial accounting.
Oh wait, that’s right, software isn’t a business, it’s a roulette wheel, so carry on!
EBITDA! Wheeeeee!
Oh wait, that’s right, software isn’t a business, it’s a roulette wheel, so carry on!
EBITDA! Wheeeeee!
no
https://c2.com/doc/oopsla92.html