I've seen the end result of this a lot working in systems integration and engineering. The problem is that, yes, most functionality has been written in some library or available through a public API, web service, whatever. Especially with mobile stuff, Apple/Google/Microsoft give the developer huge amounts of pre-built functionality, and encourage its use.
The overall problems with it are, in my mind,
- Developers and systems people not knowing how that huge chunk of functionality they use actually does what it does
- Introducing dependencies on third party applications which may or may not be around later, have spotty support, etc.
- Making applications more complex to deploy and debug -- "is this my bug or the API's bug? Why is a single row database update taking 45 seconds and 100% of a CPU core?"
The reverse problem on the other hand has the potential to be worse. No one should be coding core functionality that has the potential to fail spectacularly or have major security problems. Examples might be writing your own PKI stack instead of relying on the OS/webserver to do it, designing your own file transfer protocols unless you have a _really_ good reason, and many more. So with NIH syndrome, you have to really trust that your developers did everything right. With IH syndrome, you need to install an application, plus the 45 modules it depends on, plus provide it access to public APIs, etc.
I think the "solution", even though there's no right answer for all situations, is to make sure app developers are actually understanding development. It's too easy to write applications by gluing together pieces. With the framework movement, the pieces are much bigger and hide way more from the developer than, say, a library function.
From my side, in systems, we have way too many admins who are scared of scripting. Windows installations are moving towards PowerShell now, and while very useful, PS hides almost everything from the end user. Scripts that used to be 100 lines of loading/parsing/checking code are reduced to a single call to a chain of cmdlets. Very powerful, but the language itself isn't the most intuitive out there and borrows syntax from many languages. This leads to admins finding something on StackOverflow and copying/using it unmodified and unverified, simply because they don't know what it actually does.