5 ms·

This is a really good point. Something I've realized, tho it's, as you write, seemingly against my nature as an engineer, is that there are lots of situations

This is a really good point. Something I've realized, tho it's, as you write, seemingly against my nature as an engineer, is that there are lots of situations where it's reasonable to 'assume' technical debt to reach a more important goal. We absolutely should continue discussing technical debt, but also in the context of 'technical revenue' and 'technical profit'. Interestingly, 'technical debt' works amazingly well as a concept. I suspect it's not even really a metaphor. Consider that probably the most important pragmatic consideration about whether you should assume a debt (of any form) is whether you can expect to make all of the 'scheduled payments' that it requires. And even if you can, will you still have sufficient slack to be able to pay-off or pay-down other currently un-expected debts or expenses that you might incur between now and whenever it is you finally pay off all of the original debt?

shados 9y ago
Tech debt works great when it's done on purpose, and when the people/management who take it on are the same one who eventually deal with it. It takes a level of organization maturity to do that though. What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was). Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch. This level of industry immaturity prevents the tech debt concept from fully working. In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.
- seanmcdirmid 9y ago
  Bits conceptually rot, an unmaintained system will eventually fall apart. There isn’t just tech debt to think about, but tech depreciation.
  - orclev 9y ago
    Not just that, source code should really be viewed as a toxic byproduct, the more of it you generate, the more you're going to be paying in maintaining and managing it. The best code you can write, is the code that meets your current needs in as succinct a way as possible. Further anything that's internet facing is even more critical to minimize, failure to properly deal with it (keep it up to date and stay on top of known vulnerabilities) can and will sink a business when that bit rot eventually leads to an Experian type situation.
    - aeorgnoieang 9y ago
      The best code is the code you didn't even have to write! [I think Jeff Atwood said or wrote this, tho he may not be the original originator either.]
- majormajor 9y ago
  In most orgs like this that I've seen, it leads to a fundamental misunderstanding of tech debt. Messy code is painful so the answer is sought, when we don't have much experience, in what we learned in classes and books: elegant abstractions. But we end up abstracting business logic in such a way that when the business needs to change, our code can't change with it, and that's when we have true tech debt of the "let's rewrite the world!" sort. It might be beautifully designed abstraction, but if it's tied to the features of yesterday too much, it's going to become increasingly brittle and painful. Now when someone says "we can ship this sooner but it'll be hacky and introduce tech debt to make the code re-usable" I'm much happier, and would rather have the code not be intended to be re-used until we prove that we understand how we'll want to use it next time.
subwayclub 9y ago
I don't think there is a "technical profit" to be had, though. The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use. For tech to be useful it has to succeed at creating enough leverage that you would use it over what was there previously, and plenty of technical projects get stuck on that point: they show an immense engineering effort but are solving the wrong problem because they don't optimize the desired workflow, or they expect everything to change around the product's workflow. In that light, in a universe where most of these designs are bad and misguided and deserve to be put out to pasture, the cost-center mentality makes total sense because it asks the design to prove itself as early as possible. And the outcome of that in turn is the familiar rushed, unmaintainable prototype-in-production scenario. New technology efforts always have this element of being a judo match: if you can find just the right time and place to strike and take the problem off-balance you can get an instant win, but the same strategy at a different moment doesn't work at all, no matter how hard you flex your coding muscles, and would leave you better off not attempting any new tech. The balance-sheet model doesn't explain when and where to strike, though. It just says whether or not you're trying to do so this quarter, and any benefit will most likely show up on a different business unit's balance sheet.
- snoman 9y ago
  > I don't think there is a "technical profit" to be had, though. Ostensibly, every net-new feature increases the pool of people for whom the software, as a whole, solves a problem. The performance and usability of that feature further adds to that.* I'd argue that is technical profit, and is realized into real profit when it converts to purchases/subscriptions/whatnot. [1] For the sake of argument I'm assuming a scenario where the feature and its performance/usability is positively received.
- aeorgnoieang 9y ago
  > The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use. Technical profit is a feature or capability really that's possible because of some technical thing (e.g. code). But the 'revenue' of the capability has to exceed the cost of designing, developing – and maintaining – the tech for a profit to be realized.
nine_k 9y ago
This idea that "technical debt" is a misnomer appeals to me: http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-...
- deleted 9y ago
  [deleted]
KKKKkkkk1 9y ago
I always thought of technical debt as something that sloppy engineers knowingly or unknowingly assume on behalf of clueless managers. Kind of like a company accountant assuming debt without company officers knowing or caring. I guess I've never had the chance to see competent people make a knowledgable decision to write lousy software.
- lovich 9y ago
  Really? You've never had a manager tell you do this or it's your job? There are tons of places that do not give a single shit about good software and not even because they don't realize it's going to hurt later. When a bosses bonus is tied to quarterly results then quality goes out the window every time immediate revenue or cost cutting comes up
- aeorgnoieang 9y ago
  But it's not just applicable to lousy software. Even great software is never perfect and making tradeoffs about the design or architecture, or even just the timing of when different components, refactorings, etc. are implemented can be reasonably considered tech debt. Debt is a liability that you typically need to make payments against; preferably at predictable intervals and of predictable amounts. Every known (and significant) bug, that isn't fixed, is tech debt. Presumably something has to be done about the effects of the bug and that something has a cost. Fixing the bug then is paying down the associated debt.
tboyd47 9y ago
I like to think there's a hidden mirror analogy of "tech debt," which is the "time discount," or the notion that the longer you wait to actualize a monetary gain, the less valuable it is. Both concepts are drawn from finance, and if one is applicable to software, so is the other. I don't dare speak of this in engineering circles, though. I'd be chased out of the office with pitchforks...
- aeorgnoieang 9y ago
  > I don't dare speak of this in engineering circles, though. I'd be chased out of the office with pitchforks... What's the taboo implication that you expect the people in your engineering circles to fear or otherwise react negatively? The idea of paying down tech debt sooner than later?
  - tboyd47 9y ago
    The "monetary gain" I'm referring to here would be the software itself. So it's the idea of software being intrinsically more valuable the sooner you get it out the door. ::ducks::
    - aeorgnoieang 9y ago
      Surely they know about and hate vaporware themselves! They should be ducking!

shados 9y ago

Tech debt works great when it's done on purpose, and when the people/management who take it on are the same one who eventually deal with it. It takes a level of organization maturity to do that though. What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was). Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch. This level of industry immaturity prevents the tech debt concept from fully working. In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.

seanmcdirmid 9y ago
Bits conceptually rot, an unmaintained system will eventually fall apart. There isn’t just tech debt to think about, but tech depreciation.
- orclev 9y ago
  Not just that, source code should really be viewed as a toxic byproduct, the more of it you generate, the more you're going to be paying in maintaining and managing it. The best code you can write, is the code that meets your current needs in as succinct a way as possible. Further anything that's internet facing is even more critical to minimize, failure to properly deal with it (keep it up to date and stay on top of known vulnerabilities) can and will sink a business when that bit rot eventually leads to an Experian type situation.
  - aeorgnoieang 9y ago
    The best code is the code you didn't even have to write! [I think Jeff Atwood said or wrote this, tho he may not be the original originator either.]
majormajor 9y ago
In most orgs like this that I've seen, it leads to a fundamental misunderstanding of tech debt. Messy code is painful so the answer is sought, when we don't have much experience, in what we learned in classes and books: elegant abstractions. But we end up abstracting business logic in such a way that when the business needs to change, our code can't change with it, and that's when we have true tech debt of the "let's rewrite the world!" sort. It might be beautifully designed abstraction, but if it's tied to the features of yesterday too much, it's going to become increasingly brittle and painful. Now when someone says "we can ship this sooner but it'll be hacky and introduce tech debt to make the code re-usable" I'm much happier, and would rather have the code not be intended to be re-used until we prove that we understand how we'll want to use it next time.

subwayclub 9y ago

I don't think there is a "technical profit" to be had, though. The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use. For tech to be useful it has to succeed at creating enough leverage that you would use it over what was there previously, and plenty of technical projects get stuck on that point: they show an immense engineering effort but are solving the wrong problem because they don't optimize the desired workflow, or they expect everything to change around the product's workflow. In that light, in a universe where most of these designs are bad and misguided and deserve to be put out to pasture, the cost-center mentality makes total sense because it asks the design to prove itself as early as possible. And the outcome of that in turn is the familiar rushed, unmaintainable prototype-in-production scenario. New technology efforts always have this element of being a judo match: if you can find just the right time and place to strike and take the problem off-balance you can get an instant win, but the same strategy at a different moment doesn't work at all, no matter how hard you flex your coding muscles, and would leave you better off not attempting any new tech. The balance-sheet model doesn't explain when and where to strike, though. It just says whether or not you're trying to do so this quarter, and any benefit will most likely show up on a different business unit's balance sheet.

snoman 9y ago
> I don't think there is a "technical profit" to be had, though. Ostensibly, every net-new feature increases the pool of people for whom the software, as a whole, solves a problem. The performance and usability of that feature further adds to that.* I'd argue that is technical profit, and is realized into real profit when it converts to purchases/subscriptions/whatnot. [1] For the sake of argument I'm assuming a scenario where the feature and its performance/usability is positively received.
aeorgnoieang 9y ago
> The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use. Technical profit is a feature or capability really that's possible because of some technical thing (e.g. code). But the 'revenue' of the capability has to exceed the cost of designing, developing – and maintaining – the tech for a profit to be realized.

nine_k 9y ago

This idea that "technical debt" is a misnomer appeals to me: http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-...

deleted 9y ago
[deleted]

KKKKkkkk1 9y ago

I always thought of technical debt as something that sloppy engineers knowingly or unknowingly assume on behalf of clueless managers. Kind of like a company accountant assuming debt without company officers knowing or caring. I guess I've never had the chance to see competent people make a knowledgable decision to write lousy software.

lovich 9y ago
Really? You've never had a manager tell you do this or it's your job? There are tons of places that do not give a single shit about good software and not even because they don't realize it's going to hurt later. When a bosses bonus is tied to quarterly results then quality goes out the window every time immediate revenue or cost cutting comes up
aeorgnoieang 9y ago
But it's not just applicable to lousy software. Even great software is never perfect and making tradeoffs about the design or architecture, or even just the timing of when different components, refactorings, etc. are implemented can be reasonably considered tech debt. Debt is a liability that you typically need to make payments against; preferably at predictable intervals and of predictable amounts. Every known (and significant) bug, that isn't fixed, is tech debt. Presumably something has to be done about the effects of the bug and that something has a cost. Fixing the bug then is paying down the associated debt.

tboyd47 9y ago

I like to think there's a hidden mirror analogy of "tech debt," which is the "time discount," or the notion that the longer you wait to actualize a monetary gain, the less valuable it is. Both concepts are drawn from finance, and if one is applicable to software, so is the other. I don't dare speak of this in engineering circles, though. I'd be chased out of the office with pitchforks...

aeorgnoieang 9y ago
> I don't dare speak of this in engineering circles, though. I'd be chased out of the office with pitchforks... What's the taboo implication that you expect the people in your engineering circles to fear or otherwise react negatively? The idea of paying down tech debt sooner than later?
- tboyd47 9y ago
  The "monetary gain" I'm referring to here would be the software itself. So it's the idea of software being intrinsically more valuable the sooner you get it out the door. ::ducks::
  - aeorgnoieang 9y ago
    Surely they know about and hate vaporware themselves! They should be ducking!