The main problem is that many developers will increase technical debt when they try to fix it. For example, some will try to fix technical debt by writing a new framework. Then the new framework doesn't handle all edge cases, so you still need the old solution. Now you have two different conflicting styles creating more technical debt. The next developer will come in, see the mess, and promptly start working on a framework to consolidate everything...

So whenever you consider fixing technical debt, ask yourself if the team is skilled enough to actually create a cleaner solution. If they can't then it is just a waste of time. The best predictor of this is that they have created a cleaner solution elsewhere, if they haven't then don't let them work on technical debt unless they have an extremely well thought out plan.

Management's solution is often to hire more software engineers.

Ironically in big corporations I think that this actually plays into their underlying desires - giving a boost to headcount gives them more importance and having more developers means that the leverage each engineer has is commensurately less.

I've worked on more than a few projects which would have proceeded 4x faster with 2 good developers on a clean code base than the 7 they actually had.

Indeed the entire software startup industry is probably reliant upon this dynamic.

Not the software startup industry, unless you're flush in easy VC cash. Most of the startups which are trying to solve real problems that I've known/interviewed for are extremely conservative with hiring, for the very good reason that bad hires are not just a 0 value add, then can be a negative value add.

Uber is one of the outliers in this regard. But if you look at most successful others (Instagram, Whatsapp and a bunch of others I don't want to name since I want to stay anonymous) all had very small teams right until they were acquired.

I meant that the startup industry would be hollowed out if large corps didn't exhibit this dysfunction and thus create space in the market for them, not that startups do it themselves (although occasionally they do too).

Ah, that does makes sense. Apologies for misunderstanding.

My experience is that these companies have the worst kind of technical debt: a prematurely optimised and poorly abstracted codebase, due to non senior engineers refactoring just in case. Non abstracted codebases are boring to work with because the same code is duplicated, but they are not that difficult to change or add feature to. Extreme DRY on the other hand are the kind of codebase everyone is afraid to touch. Sure maybe they had 100% test coverage in their days, too bad adding a new feature with a small model change would break every interwined object factory.

It's not just extremely DRY stuff that can be problematic.

I work in a non-abstracted code base, but all that really means is every time someone wanted to do something they simply wrote their own way of doing it. Needless to say it's suboptimal to work in on the best of days.

People like to deride one way of doing things vs another but in reality pretty much every approach to software development and architecture can be amazing or hellish depending on the aggregate quality of the developers, their management and the lines of communication between them.

TL;DR - Bad code is bad no matter the paradigm and all paradigms can be made awful.

I think you and grandparent post's author are both right. I've seen both. It depends on the type of engineers that inhabit your team, and therefore are not mutually exclusive.