5 ms·

This is a really profound point about software. The ironic thing is that this "cost-center culture" has even affected the mindset of individual software develo

This is a really profound point about software. The ironic thing is that this "cost-center culture" has even affected the mindset of individual software developers and how we think of our own work. Most developers ONLY look at their work in terms of cost. ALL pros and cons arguments are really about ways to reduce cost. Consider the term "tech debt" -- nothing could be clearer. Yet discussions rarely ever take place among engineers at a company about how to maximize profit or increase revenue. In fact, I would argue there is a heavy cultural bias on most engineering AGAINST optimizing for revenue, as it is seen as something that motivates sales or product people to rush timelines and sabotage sound engineering practices. The obsession with cost is baked into programmer culture in such a deep and foundational way, I'm skeptical will ever change, even if the accounting of software projects changes. If you perform a search for the word "cost" on the eBook for the Principles of Object-Oriented Design in Ruby by Sandi Metz, you will find it dozens of times in various sentences about the urgency and critical importance of reducing costs, but the words "profit," "income," or "revenue" appear not even once. I'm not trying to make a point about POODR in particular, because this bias is only reflective of the culture as a whole. You can certainly make the argument that it has to be that way, and engineering should be separated from revenue. I find it very interesting that, as a culture, we are only willing to speak about the monetary value of our work in negative terms.

deleted 9y ago
[deleted]
paulddraper 9y ago
That's not specific to software at all. Talk to any electrical, mechanical, or civil engineer and they will be focusing on getting this on time and under budget, not trying to increase "income" or "revenue".
- HeyLaughingBoy 9y ago
  It's far more prevalent in software though. Those other fields realize that incurring any technical debt is going to involve very expensive repayment. One of Boehm's "fundamental problems of software" is that it's so easy to change, that it's easy to assume that you can always change it later at no cost. This is really why the problem is far greater in software.
aeorgnoieang 9y ago
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.
    - 9y ago
mark-r 9y ago
I'm not sure your thinking applies to the term "technical debt". It's simply a way of phrasing the downsides of crufty old code in a way everybody can understand. If you really want to stretch the analogy, you take on debt to get a tangible immediate benefit - wouldn't the benefit be maximized profit or increased revenue?
Terr_ 9y ago
> but the words "profit," "income," or "revenue" appear not even once. That may be because those mechanisms are usually much more situation- and industry-specific, it's the X that software lets you do. Conversely, software costs are the part that is more generalizable in a book about software.
- tboyd47 9y ago
  I would agree with you if the cost bias were only found in her book. But the bias is literally everywhere you go, on every engineering team. It's all we ever talk about. At the CEO level, the money-making potential of software is clearly understood, so why, at the ground level, is it the exact opposite? Every programmer is paranoid about the costs they're introducing to an organization while totally ignoring the financial upsides. Every discussion is "cost now vs. cost later." If our only goal at work is to minimize the cost to our companies, then our managers can do that better than us: he can just fire us and cancel the project. There, cost is now zero.
justinjlynn 9y ago
Technical debt isn't debt, it's an uncovered short sale. The thing is, debt is controllable; it has interest, you can pay it down. When "tech debt" becomes payable and due, it's payable and due now; at any cost, or the project fails.
- provost 9y ago
  This is a clever analogy. Did you get this from somewhere? I'm curious what other finance analogies mix with IT/business?
  - justinjlynn 9y ago
    Not originally my idea, no: https://web.archive.org/web/20111125070500/http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ https://web.archive.org/web/20111125070500/http://www.higher...

deleted 9y ago

[deleted]

paulddraper 9y ago

That's not specific to software at all. Talk to any electrical, mechanical, or civil engineer and they will be focusing on getting this on time and under budget, not trying to increase "income" or "revenue".

HeyLaughingBoy 9y ago
It's far more prevalent in software though. Those other fields realize that incurring any technical debt is going to involve very expensive repayment. One of Boehm's "fundamental problems of software" is that it's so easy to change, that it's easy to assume that you can always change it later at no cost. This is really why the problem is far greater in software.

aeorgnoieang 9y ago

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.
  - 9y ago

mark-r 9y ago

I'm not sure your thinking applies to the term "technical debt". It's simply a way of phrasing the downsides of crufty old code in a way everybody can understand. If you really want to stretch the analogy, you take on debt to get a tangible immediate benefit - wouldn't the benefit be maximized profit or increased revenue?

Terr_ 9y ago

> but the words "profit," "income," or "revenue" appear not even once. That may be because those mechanisms are usually much more situation- and industry-specific, it's the X that software lets you do. Conversely, software costs are the part that is more generalizable in a book about software.

tboyd47 9y ago
I would agree with you if the cost bias were only found in her book. But the bias is literally everywhere you go, on every engineering team. It's all we ever talk about. At the CEO level, the money-making potential of software is clearly understood, so why, at the ground level, is it the exact opposite? Every programmer is paranoid about the costs they're introducing to an organization while totally ignoring the financial upsides. Every discussion is "cost now vs. cost later." If our only goal at work is to minimize the cost to our companies, then our managers can do that better than us: he can just fire us and cancel the project. There, cost is now zero.

justinjlynn 9y ago

Technical debt isn't debt, it's an uncovered short sale. The thing is, debt is controllable; it has interest, you can pay it down. When "tech debt" becomes payable and due, it's payable and due now; at any cost, or the project fails.

provost 9y ago
This is a clever analogy. Did you get this from somewhere? I'm curious what other finance analogies mix with IT/business?
- justinjlynn 9y ago
  Not originally my idea, no: https://web.archive.org/web/20111125070500/http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ https://web.archive.org/web/20111125070500/http://www.higher...