I might be reading this the wrong way, but this helps explain the Not-Invented-Here syndrome [1]. Why not just re-use some other code? Because it's not just about the code, but about the programming team's understanding of how the software tackles the problem.
However, the rational way to do it would be to try and read the outside code and reuse it as much as possible. In the same way that you read a book on Calculus and do not need to write a new one if you have learnt it.
But we humans are anything but rational.
In a sense, doing those exercises is "rewriting calculus" in a form that is internalized for yourself. It's the same as learning to play a piece of music: if you're a good piano player, you can read the sheet music for a Beethoven sonata and have an idea of what it's like [0], but you need to practice the piece to really understand what it means.
Maybe the design of software should also contain some kind of built-in learning process. When one encounters a new codebase, it can take quite a while to figure out where to even start deciphering the architecture... What if there was a design document with a textbook-like approach that extended all the way into the code itself: there would be "exercise hooks" expressly for the purpose of allowing a programmer to experiment with the software's internals in a controlled fashion.
- -
[0] I guess -- I suck at music, so I wouldn't really know.
An actual rewriting of calculus would involve discovering proofs for things like the Mean-Value Theorem or the Fundamental Theorem of Calculus. Short of that, you could wrestle with trying to discover proofs for theorems so that you can at least appreciate the canonical ones. Incidentally, this is what every mathematics major has to do in order to earn their degree.
Thus, NIH may really just be a want of a theorem (sometimes merely a stronger one).
I shall use the word programming to denote the whole
activity of design and implementation of programmed
solutions.