5 ms·

Stop Saying "Technical Debt"

21 points by BerislavLopac 3y ago

alkz 3y ago
no
blitzar 3y ago
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.
williamcotton 3y ago
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!
hyperman1 3y ago
Afaik, the original term came from Cunningham, and was well defined. It got diluted and abused until it lost its meaning, just like so much other terms https://c2.com/doc/oopsla92.html 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 [...].
- karmakaze 3y ago
  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.
  - Bjartr 3y ago
    How long until we get the post 'Stop Saying "Technical Debt", Considered Harmful'?
  - c-linkage 3y ago
    Roy Fielding has entered the chat. https://en.m.wikipedia.org/wiki/Representational_state_transfer https://en.m.wikipedia.org/wiki/Representational_state_trans... https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
williamcotton 3y ago
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.
- wjnc 3y ago
  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.
  - williamcotton 3y ago
    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!
    - williamcotton 3y ago
      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!
gbin 3y ago
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.
thegreen1337 3y ago
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.
hmeh 3y ago
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/master/technical-debt-vs-incomplete-work.md#technical-debt-vs-incomplete-work 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.
JohnFen 3y ago
> 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".
Havoc 3y ago
A bit like “XYZ considered harmful”. Sounds so awkward to me but people seem to love it
c-linkage 3y ago
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.
deterministic 3y ago
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.

21 points by BerislavLopac 3y ago

alkz 3y ago

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.

williamcotton 3y ago

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!

hyperman1 3y ago

Afaik, the original term came from Cunningham, and was well defined. It got diluted and abused until it lost its meaning, just like so much other terms https://c2.com/doc/oopsla92.html 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 [...].

karmakaze 3y ago
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.
- Bjartr 3y ago
  How long until we get the post 'Stop Saying "Technical Debt", Considered Harmful'?
- c-linkage 3y ago
  Roy Fielding has entered the chat. https://en.m.wikipedia.org/wiki/Representational_state_transfer https://en.m.wikipedia.org/wiki/Representational_state_trans... https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

williamcotton 3y ago

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.

wjnc 3y ago
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.
- williamcotton 3y ago
  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!
  - williamcotton 3y ago
    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!

gbin 3y ago

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.

thegreen1337 3y ago

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.

hmeh 3y ago

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/master/technical-debt-vs-incomplete-work.md#technical-debt-vs-incomplete-work 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.

JohnFen 3y ago

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

Havoc 3y ago

A bit like “XYZ considered harmful”. Sounds so awkward to me but people seem to love it

c-linkage 3y ago

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.

deterministic 3y ago

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.