3 ms·

Paying technical debt down takes away from other areas you can grow on. Unfortunately the economics doesnt play out like this. Whether you have technical debt

Paying technical debt down takes away from other areas you can grow on. Unfortunately the economics doesnt play out like this. Whether you have technical debt or not, the stack will get a rewrite every now and then because thats how senior ics will like it or will get promoted because of it. I have seen lots of infra churn that went over budget, didnt result in the impact it claimed, and so on. Technical debt is overrated.

barrkel 7y ago
Even when technical debt is deliberately taken on in the interest of growth, it still can come around to bite you, as you triple and quintuple the size of the team yet see only 20% increase in velocity, and face further dilution to maintain growth momentum. (Yes, technical debt is often overrated, by young engineers unused to maintaining hairy code. But when it builds up over several years, it can add up to a real problem.)
- tehlike 7y ago
  Sure, but you will find out that eng has more desire to rewrite than gradually increase quality. Meaning... When you choose your debt reduction strategy, you cannot go 0% debt. There will be investments you can do, like increasing deployment velocity, adding monitoring and so on, but refactoring that ugly god object may not be the greatest idea.
  - barrkel 7y ago
    There's little point rewriting code which isn't modified often. And actually it's code which is modified often which accumulates design debt; structure tends to "dissolve" in the face of repeated local modifications by engineers on a time budget who don't understand the whole and don't know where to make the right changes. Ugly code which is locked away in a module isn't a big deal unless it's a performance problem or bug magnet. I wouldn't really consider that stuff debt, though; if it's not impeding velocity, you're not paying interest on it. Technical debt which has a noticeable interest payment, that's worth reducing. Sometimes the interest cost isn't obvious. E.g. the UI might be written using some framework which is 5 years old; it might be reasonably clean internally, but the payment comes from developer churn and lack of appeal to devs (whether current or pending hire) wanting to keep their CVs up to date. That cost is real, yet it's imposed exogenously, not because of any deficiencies in the actual technology.
    - tehlike 7y ago
      "wanting to keep their CVs up to date" This is part of my point. The eng could have spent 6 more months on making that UI even better, only to have another eng rewrite it in 5 years because... why not.
Ericson2314 7y ago
I'm very lucky where at my job technical decisions are actually deemed meaningful gasp and so are made consistently for the entire company. Most places I gather the non-technical people in charge assume they don't matter so they're basically left as fodder to appease dev leads and make them feel important/creative.
- tehlike 7y ago
  Most of it comes down to short-term and long term view of people in charge. Unfortunately, companies do promote short term gains. Promo cycles are 1-1.5 years long for most companies, as a result people tend to optimize for launching. For managers, in FAANG, that seem to go around # of people that report to you, so they optimize for that. For a business, there's less incentive to do that investment. You need _some_ investment to keep it long term, but you don't need to put your 100% to make it work. It also comes down to VP of Engineering or equivalent in an org. Not overdoing technical debt is key. It's a means to an end, the end goal is still $$.

barrkel 7y ago

Even when technical debt is deliberately taken on in the interest of growth, it still can come around to bite you, as you triple and quintuple the size of the team yet see only 20% increase in velocity, and face further dilution to maintain growth momentum. (Yes, technical debt is often overrated, by young engineers unused to maintaining hairy code. But when it builds up over several years, it can add up to a real problem.)

tehlike 7y ago
Sure, but you will find out that eng has more desire to rewrite than gradually increase quality. Meaning... When you choose your debt reduction strategy, you cannot go 0% debt. There will be investments you can do, like increasing deployment velocity, adding monitoring and so on, but refactoring that ugly god object may not be the greatest idea.
- barrkel 7y ago
  There's little point rewriting code which isn't modified often. And actually it's code which is modified often which accumulates design debt; structure tends to "dissolve" in the face of repeated local modifications by engineers on a time budget who don't understand the whole and don't know where to make the right changes. Ugly code which is locked away in a module isn't a big deal unless it's a performance problem or bug magnet. I wouldn't really consider that stuff debt, though; if it's not impeding velocity, you're not paying interest on it. Technical debt which has a noticeable interest payment, that's worth reducing. Sometimes the interest cost isn't obvious. E.g. the UI might be written using some framework which is 5 years old; it might be reasonably clean internally, but the payment comes from developer churn and lack of appeal to devs (whether current or pending hire) wanting to keep their CVs up to date. That cost is real, yet it's imposed exogenously, not because of any deficiencies in the actual technology.
  - tehlike 7y ago
    "wanting to keep their CVs up to date" This is part of my point. The eng could have spent 6 more months on making that UI even better, only to have another eng rewrite it in 5 years because... why not.

Ericson2314 7y ago

I'm very lucky where at my job technical decisions are actually deemed meaningful gasp and so are made consistently for the entire company. Most places I gather the non-technical people in charge assume they don't matter so they're basically left as fodder to appease dev leads and make them feel important/creative.

tehlike 7y ago
Most of it comes down to short-term and long term view of people in charge. Unfortunately, companies do promote short term gains. Promo cycles are 1-1.5 years long for most companies, as a result people tend to optimize for launching. For managers, in FAANG, that seem to go around # of people that report to you, so they optimize for that. For a business, there's less incentive to do that investment. You need _some_ investment to keep it long term, but you don't need to put your 100% to make it work. It also comes down to VP of Engineering or equivalent in an org. Not overdoing technical debt is key. It's a means to an end, the end goal is still $$.