Stop Saying "Technical Debt"
stackoverflow.blog
stackoverflow.blog
https://c2.com/doc/oopsla92.html
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. [...] The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation [...].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.
https://en.m.wikipedia.org/wiki/Representational_state_trans...
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
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.
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 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!
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 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".
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 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 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.
In the words of a former president - It depends on what the meaning of the word 'is' is.
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.
Oh wait, that’s right, software isn’t a business, it’s a roulette wheel, so carry on!
EBITDA! Wheeeeee!