They usually have enormous technical debt that elite engineers could disentangle.
Doing so will not be recognised nor appreciated by management.
That one month project could probably be split in to 5 smaller but still meaningful ones.
Agreed. It should be part of the normal workflow and not much talked about.
Heck, even other devs don’t see technical debt as problem. It’s more of a political problem, less technical.
I mean this as a message of hope, not a quibble!
I'd say tech debt is more like a special VAT applied to your current actions, whereas regular debt is proportional only to your past actions.
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.
(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.)
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.
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.
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.
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.
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 $$.
You can always cheap out and get it done slightly faster and slightly cheaper. And you might not have to suffer the consequences. But someone down the line likely will.
E.g. we recently had to install a cleanout for the sewer mainline in our house. Apparently when they built the house, they did everything but install the final above-ground cleanout - instead they just capped it off below ground. The other work, except for the above ground part, all had to be done for testing purposes anyways. But by not installing the above ground part they managed to save something like $10 for each house they built. But now, instead, I had to pay a company $1,200 in labor (they spent all day digging) to install a $20 part when our sewer backed up.
I work in a codebase full of bad, willful technical debt like this. "Let's just do it the easy way" - despite the "hard" way not being harder, just more different than they were used to at the time. Or hard coding things despite being able to derive it from other information - "we can do it later" - good luck, differences creep in and you will spend weeks or even months figuring out all these minor differences and whether they are on accident or on purpose.
6 months down the line, that easy way is completely fucking us up. Certain changes that would have taken an hour take days. And it was completely predictable at the time.
In a similar analogy to yours, most of these systems tend to cause outage somewhere, which are then usually patched on the fly. Depending on a project, shipping fast is usually more valuable than not shipping it for a year. From my pov, i used to be in advertising, and not releasing a billion dollar feature for a year would, by definition, cost a billion dollars a year. If it explodes after releasing, you are still better of by a huge marging because outage would cost much less. Once you have the business going, you can spend money and manpower on the problem, too.
I think this is key: "Hard way not being harder". This depends. Engineers like to overengineer, and without proper supervision they tend to favor technical excellence over business usecase - it needs to be a balance.
On the house example, i bet the value of your house still increased, and the 1500$ you paid is irrelevant in the grand scheme of things. Just like business & rewrite.
Overall, don't get me wrong, I like to use my best skills and put a shiny design out, but i don't do it because I favor doing "good enough".
I can clean up any mess better than most, and I actually enjoy it.
To me refactoring is the design process of modern development. First you write the working code, and then yo design it. Except most people don't bother with the design part, and get dragged down by their atrophied systems.