This gets at an interesting nuance. The under-reliance on dependencies actually poses issues at a system level, not at an individual product level, which makes it hard to sell business types on the existence of the problem.
Is it really hard to replace engineers when you have a lot of dependencies? A lot of dependencies means a lot of things you have to learn. Let's consider the case where every line of code invokes a different dependency. That's clearly insane and not the ideal case, even if they are all well-known dependencies. Everyone on the team will be constantly chasing down documentation for the dependencies they don't know.
The optimal point is somewhere in the middle. I just am pushing for more dependencies because I see it being too far in the "no dependencies" direction.
Is it really hard to replace engineers when you have a lot of dependencies? A lot of dependencies means a lot of things you have to learn. Let's consider the case where every line of code invokes a different dependency. That's clearly insane and not the ideal case, even if they are all well-known dependencies. Everyone on the team will be constantly chasing down documentation for the dependencies they don't know.
The optimal point is somewhere in the middle. I just am pushing for more dependencies because I see it being too far in the "no dependencies" direction.