Not invented here, revisited
theengineeringmanager.com
theengineeringmanager.com
How many bugs do fix by removing complexity that is unnecessary for your special case?
Or perhaps not, because there's a chance people already forgot about the left-pad incident.
Terry Pratchett
>The opposite predisposition is sometimes called "proudly found elsewhere" (PFE) or "invented elsewhere".
Every system has its own sets of constraints, and its own sets of goals. Those constraints and goals don't necessarily align with the assumptions made in the library you're using, because it's rare to have a library that does precisely what you need.
When you can't find a library that meets your needs, you have two choices: 1) roll your own solution, or 2) find a library that does something similar to what you want, and coerce the library into a form that suits your needs.
Neither are pleasant options, but I find #1 tends to give a better outcome in the long run. You know what your system constraints are, so you're in a better position to design around them.
Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.
I think the question is always, how smart an engineer can you be to reuse the maximal amount possible to deliver a good experience quickly.
The three rules of software development:
1. Don't write code as there is a library that already does exactly what you want to do
2. Don't write code because you can combine several libraries to do what you want to do
3. Don't write code because there is some mega-framework, one subset of which does what you want to do
In my experience, it's more like "due to an uncontrollable urge that building technology in-house will be more fun, more interesting, more pleasing than using an existing solution" :)
...not that I'm completely innocent in this respect.
Indeed, retention is valuable.
> Some NIH will give your best staff something to really get their teeth into. A chance to create. A chance to contribute something original. An incentive to remain at your company.
Although it's not saying fun, pleasing, or interesting, it could be argued that this is what is meant, just with a more positive spin.
What's notably missing is whether the original, meaty creation provides value beyond retention (which a sibling comment points out does, indeed, have value).
Possible value to the staff is improved (or at least kept honed) skills, and possible value can go to the community for anything open-sourced. Of course, the latter can result in a proliferation of options that result in a "paralysis of choice" for which the article has an entire section.