4 ms·

Technical debt's main difference from financial debt is that it can't really be quantified, because it's hard to really identify. Most software has a lifetime,

Technical debt's main difference from financial debt is that it can't really be quantified, because it's hard to really identify. Most software has a lifetime, initiatives don't maintain economic value indefinitely. At the end of that lifetime, the lights get shut off and the code mothballed, never to see the light of day again. At that point, the balance sheet hits zero and you never have to pay it back. Software where this doesn't happen eventually has the kinks filed away. Old Fortran codebases and the like have fixed maintenance costs and are worked on by savvy greybeards who are excellent at providing their own job security. Nobody wants to rock that boat, and nobody does. The greybeards are the ones who pay off the debt because it's their livelihoods that get threatened by instability. Management just keeps happily writing checks, devoting their attention to squeakier wheels. So it's a tradeoff. Initial greenfield development by one dev or a small team eventually gives way to the bread-and-butter of keeping projects responsive to economic needs. What we call technical debt is really just architectural problems made both from inexperience, and from not specifying the requirements of the project well enough. Decisions made by the greenfield team add to the friction that the maintainers experience in steering the ship. The problems need to be identified and corrected in the course of the maintenance. Unfortunately most devs are not really capable of remaining productive while fixing architectural issues, so management perceives this as prioritizing the needs of the devs over the needs of the business and so tend to balk at putting resources into paying off debt.

weinzierl 10y ago
> Most software has a lifetime, initiatives don't maintain economic value indefinitely. Most software is rewritten many times before it's initiative loses its economic value most of the time for political reasons sometimes because it accrued too much technical debt.
- hackits 10y ago
  Mostly rewritten because they business needs change. Software is there to service the business not the other way around.
Spooky23 10y ago
The article uses an infrastructure example. That's a much more predictable type of technical debt. Even then, orgs are terrible at managing risk and costs. In my first job, I was a DBA managing a big reservation system somehow (the how is a funny story too). They had an issue where someone fubared the initial database config, leaving us with a time bomb. Critical tables were beyond the number of tablespace extents supported, and there was a 100% probability that the database would essentially freeze up to avoid data loss. We came up with a plan that would eliminate the risk, but would require an extended maintenance window, which translates into a 4-hour SLA hit. Cost:$20k or less. The SVP said no, there's no budget for an SLA hit, wait for Christmas holiday downtime (6 months away). Two weeks later, on the busiest business day of the year, database is frozen at 9AM. It took us 48 hours to restore as we needed to restore everything and fix some corruption. Each hour of downtime cost $7,000/hr in wasted labor in the business, and the SLA penalty was harsh. It's an egregious example, but I've seen lots of similarly dumb decision making in my career.
- vinceguidry 10y ago
  > someone fubared the initial database config Utter incompetence. Developers seem to have this almost-magical ability to blame management for their fuck-ups. Guess I can't blame them too much, there's practically no decent software engineering training anymore. All we get is irrelevant science-y shit. > We came up with a plan that would eliminate the risk, You don't call it a risk if there's a 100% chance. Managers are not going to understand scenarios you put in front of them, you have to guide the conversation. You say, "this is going to happen if we don't fix this right effing now." Then you threaten to quit if they don't take you seriously. But again, professional pride is something nobody teaches developers.
  - hackits 10y ago
    I would say that the threatening to quit because they don't take you seriously kind of re-inforces their view point why they don't you take you seriously in the first point.
    - 10y ago

weinzierl 10y ago

> Most software has a lifetime, initiatives don't maintain economic value indefinitely. Most software is rewritten many times before it's initiative loses its economic value most of the time for political reasons sometimes because it accrued too much technical debt.

hackits 10y ago
Mostly rewritten because they business needs change. Software is there to service the business not the other way around.

Spooky23 10y ago

The article uses an infrastructure example. That's a much more predictable type of technical debt. Even then, orgs are terrible at managing risk and costs. In my first job, I was a DBA managing a big reservation system somehow (the how is a funny story too). They had an issue where someone fubared the initial database config, leaving us with a time bomb. Critical tables were beyond the number of tablespace extents supported, and there was a 100% probability that the database would essentially freeze up to avoid data loss. We came up with a plan that would eliminate the risk, but would require an extended maintenance window, which translates into a 4-hour SLA hit. Cost:$20k or less. The SVP said no, there's no budget for an SLA hit, wait for Christmas holiday downtime (6 months away). Two weeks later, on the busiest business day of the year, database is frozen at 9AM. It took us 48 hours to restore as we needed to restore everything and fix some corruption. Each hour of downtime cost $7,000/hr in wasted labor in the business, and the SLA penalty was harsh. It's an egregious example, but I've seen lots of similarly dumb decision making in my career.

vinceguidry 10y ago
> someone fubared the initial database config Utter incompetence. Developers seem to have this almost-magical ability to blame management for their fuck-ups. Guess I can't blame them too much, there's practically no decent software engineering training anymore. All we get is irrelevant science-y shit. > We came up with a plan that would eliminate the risk, You don't call it a risk if there's a 100% chance. Managers are not going to understand scenarios you put in front of them, you have to guide the conversation. You say, "this is going to happen if we don't fix this right effing now." Then you threaten to quit if they don't take you seriously. But again, professional pride is something nobody teaches developers.
- hackits 10y ago
  I would say that the threatening to quit because they don't take you seriously kind of re-inforces their view point why they don't you take you seriously in the first point.
  - 10y ago