4 ms·

> But there's a huge swath of dev shops that never pay any technical debt back Engineers often talk about technical debt as if the codebase is the currency of

by unoti 10y ago

> But there's a huge swath of dev shops that never pay any technical debt back Engineers often talk about technical debt as if the codebase is the currency of the realm. It's not. Business Value is the currency of the realm. The code is something that facilitates business value, when (and only when) it does what the business needs. The people working on the code have a customer, the business. The business is locked in to a single provider for that service. And the service provider has grown complacent, prioritizing its own needs and processes ahead of the needs of the customer. They're behaving like other entrenched and untouchable service providers do, in monopoly industries like government and cable companies. Deal with my service levels, or suck it. There are many customer-obsessed engineers who know how to strike this balance, but this is one of the many issues where there's selection bias in who will take the time to participate in the discussion. People who think this is a powerful story of IT done right need to broaden their minds, stop playing around on hacker news, and start thinking a little broader about how software service providers can do a better job of learning how to say "yes" faster.

dragonwriter 10y ago
> Engineers often talk about technical debt as if the codebase is the currency of the realm. It's not. Business Value is the currency of the realm. "Technical Debt" is a term that exists largely to communicate the idea that the thing it represents increases the dollar cost of both operating the software to deliver constant business value in a steady state, and of delivering changes to the software to continue to deliver the same value as business needs change or to realize additional opportunities to deliver new value. It is, absolutely and centrally, about business value; ignoring it in decision-making is exactly like ignoring maintenance/operations costs in a capital purchase and considering only acquisition costs.
loco5niner 10y ago
> start thinking a little broader about how software service providers can do a better job of learning how to say "yes" faster. We don't need more "yes men", we need more people able and willing to say 'Here are the trade-offs', and work with the business from there. Yes, it absolutely is about Business Value, and the best Business Value is not always "yes" (of course, sometimes it is). ... speaking as someone currently dealing with and seeing the Business Value impact of technical debt.
SubuSS 10y ago
All tech debt need not be paid back in full - thinking otherwise is indeed a fallacy like you point out. The catch here though is the fact that rate of business value production is inversely proportional to amount of tech debt. Meaning a ton of yes's today will mean a grinding halt in a couple of years. I have worked on too many (very successful) teams now and watched many others that have gotten themselves into this situation. After this point, you end in a place where tech debt repayment efforts can take years - but it also coincides with 4-5 year mark when original developers are tired and leave. End product - a giant legacy system operated by a ton of new folk who have no clue what's up. End result: This gets 'deprecated' and replaced by a brand new one. Ideally I do think data is gold but code needs to be incrementally ripped out and replaced every 3-5 years or so. Else entropy is too crippling on the system.

by unoti 10y ago

dragonwriter 10y ago

> Engineers often talk about technical debt as if the codebase is the currency of the realm. It's not. Business Value is the currency of the realm. "Technical Debt" is a term that exists largely to communicate the idea that the thing it represents increases the dollar cost of both operating the software to deliver constant business value in a steady state, and of delivering changes to the software to continue to deliver the same value as business needs change or to realize additional opportunities to deliver new value. It is, absolutely and centrally, about business value; ignoring it in decision-making is exactly like ignoring maintenance/operations costs in a capital purchase and considering only acquisition costs.

loco5niner 10y ago

> start thinking a little broader about how software service providers can do a better job of learning how to say "yes" faster. We don't need more "yes men", we need more people able and willing to say 'Here are the trade-offs', and work with the business from there. Yes, it absolutely is about Business Value, and the best Business Value is not always "yes" (of course, sometimes it is). ... speaking as someone currently dealing with and seeing the Business Value impact of technical debt.

SubuSS 10y ago

All tech debt need not be paid back in full - thinking otherwise is indeed a fallacy like you point out. The catch here though is the fact that rate of business value production is inversely proportional to amount of tech debt. Meaning a ton of yes's today will mean a grinding halt in a couple of years. I have worked on too many (very successful) teams now and watched many others that have gotten themselves into this situation. After this point, you end in a place where tech debt repayment efforts can take years - but it also coincides with 4-5 year mark when original developers are tired and leave. End product - a giant legacy system operated by a ton of new folk who have no clue what's up. End result: This gets 'deprecated' and replaced by a brand new one. Ideally I do think data is gold but code needs to be incrementally ripped out and replaced every 3-5 years or so. Else entropy is too crippling on the system.