I've seen exactly the same thing at a couple of companies I've worked at in the past too. One specifically outsourced all of their development because it was deemed to be cheaper (which it was), but after a few years without any in-house technical expertise to oversee development they'd run into all kinds of issues with bugs, outages, slow load times, etc.
For a period when these issues occurred the business could say that they wanted the issues patched, but they never understood why there were so many issues to begin with. It was only until they brought a few people in house to try to bridge conversations between the business and the team of outsourced developers that it was finally raised that the code was completely unmaintainable. And following this an in house team was recruited to bring development back in-house. Of course, when we sorted 90% of the problems the business started questioning why we were needed again and we were all outsourced for a second time...
But this same thing obviously happens in a lot high-tech industries. Without people who are technically competent overseeing what's happening you can only dictate requirements at a high level. You cannot dictate all of the NFRs because you simply do not have the knowledge or ability to oversee them. So what you have is something that at a surface level does what you wanted, but the execution is so horrendous that it's unsatisfactory and no amount of saying "please fix this", "please fix that" will actually resolve the fundamental issue at play.
And the problem is even worse when you want to be an innovator because innovation is impossible when you don't know what is and isn't possible. To push boundaries you first need to know where the hard limitations are and what's just a engineering problem.
> You cannot dictate all of the NFRs because you simply do not have the knowledge or ability to oversee them
This is a key point, and I believe the reason why software projects are always late and why it’s impossible to estimate them generally, in a non-domain specific way.
You cannot aggregate all the estimates and recorded performance of past work and use regression towards the mean to have any predictive capacity of how long a new project will take or cost, even when it has similar high level requirements.
This is why 10xers exist, or the perception of them exists. There are people who have seen similar pitfalls in the implementation stage enough times to know how to avoid them and they don’t need to redo things as much.
This is why rewrites are dangerous, even when existing code bases are cumbersome to deal with and expensive to develop. The deep magic of low level NFRs will ruin attempts to replace them.
Some are clever and try to use linters and static analysis tools to avoid this, but these will always be opinionated, domain specific in some way, and incomplete. They can frustrate development when taken outside their domain.
I think what you're saying is true, but a slightly broader issue around why software development is difficult more generally.
What I'm touching on here is more related to how outsourced teams typically lack the ownership and motivations that internal technical teams will generally have.
The specifics will vary depending on the outsourcing model, but outsourcing to a remote software development agency is typically the worse of all possible options. The reason for this is that code quality and maintainability is rarely ever a priority for an agency because they're typically judged purely on whether they can deliver what they promised to the client on time. It's very hard to tell a client that a feature is coming 3 months late and will cost extra, but that time is needed to ensure the developers are happy with the code quality.
Additionally, if there are any bugs that's often a good thing for a software development agency because not only will you now be paid for the initial feature development, but you'll also be paid for any subsequent bug fixes.
If outsourcing is done directly then the results are typically better because the remote team tends to have more agency. The business might still ask for a feature as soon as possible, but now the remote team isn't going to receive extra work for bug fixing the crappy code they deliver. They also don't have multiple clients and are going to be working solely on that single codebase so can't just hand off any issues to the next guy who comes along. With direct outsourcing the incentive to deliver crappy code no longer exists so typically the quality increases. Additionally the business might trust the remote employees enough to judge their own performance for which they can include NFRs instead of judging performance purely on the speed at which features are delivered.
However, even if directly outsourcing employees are rarely seen as equal to other employees at the company. The business basically just sees them as cheap code monkeys and the code monkeys know that's all they'll ever be too. Employees working at head office on the other hand might be motivated to go above and beyond because they want to be recognised by their bosses, and if they do a good enough job they might even get a promotion. This just never going to happen to a code monkey in India who can barely speak English no matter how competent they are.
Additionally, a team at head office is also likely to have more influence on business decisions and be able to feed technical input into the decision making where useful. This increased influence also means employees are more likely to care about the company since they feel closer and more involved in decision making.
The reason outsourced teams are bad isn't necessarily because they're not hiring enough 10x developers (although they're often not incentivised to do that either), it's more that there's usually little real reason for anyone to produce anything of quality. No one is going to be promoted, no one has any influence, developers are mostly just being judged on how fast they can deliver features because that's the only metric non-technical individuals can assess their productivity by, and finally they're disconnected in just about every possible way (location, culturally, hierarchically, etc).
I think what might work is have a great development team in house who can make all right high level technical calls, then outsource the grunt work while assessing them both on speed and on quality. A almost every company I've worked for there are talented people wasting time on nonsense like bumping project project dependencies and replacing deprecated code. I'd guess that work could be outsourced with near-zero downside and a significant cost saving.
For a period when these issues occurred the business could say that they wanted the issues patched, but they never understood why there were so many issues to begin with. It was only until they brought a few people in house to try to bridge conversations between the business and the team of outsourced developers that it was finally raised that the code was completely unmaintainable. And following this an in house team was recruited to bring development back in-house. Of course, when we sorted 90% of the problems the business started questioning why we were needed again and we were all outsourced for a second time...
But this same thing obviously happens in a lot high-tech industries. Without people who are technically competent overseeing what's happening you can only dictate requirements at a high level. You cannot dictate all of the NFRs because you simply do not have the knowledge or ability to oversee them. So what you have is something that at a surface level does what you wanted, but the execution is so horrendous that it's unsatisfactory and no amount of saying "please fix this", "please fix that" will actually resolve the fundamental issue at play.
And the problem is even worse when you want to be an innovator because innovation is impossible when you don't know what is and isn't possible. To push boundaries you first need to know where the hard limitations are and what's just a engineering problem.