Not invented here, revisited(theengineeringmanager.com)
theengineeringmanager.com
Not invented here, revisited
http://theengineeringmanager.com/growth/not-invented-here-revisited/
30 comments
Is there a name for the opposite of NIH syndrome, where programmers only use external libraries and frameworks, and are totally allergic to the notion of writing in-house code?
If it’s commercial software, then BTF = bought the farm
For me, reusing widely used code that's heavily tested is preferable to the liability of handwritten code. If I'm given the opportunity, when possible, I'm going to choose the former.
That's a good default to start with, but that's not the whole story.
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.
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.
I feel like the problem comes down to people not willing to read the docs. Reading the freaking manual helps understand if your tools are precise enough or configurable to solve your problems. Then reading the source code (if possible).
Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.
Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.
On the other hand time required to read and _understand_ the source can be often very compareable to writing specific solution to your problem. Which all comes down to one biggest bottle neck of our industry: sharing understanding of solutions.
It needs to be a deliberate decision based on use cases. Depending on your business, it may be more valuable not to relinquish control of important functionality to third parties.
I suppose nobody really invents anything in-house in one sense. You reuse the hardware, the OS, the drivers, the network, cloud storage, IDE, source-control, JIRA, a programming language, several libraries, databases, at least one framework, and on top of all that you may have some sprinkles that are "your application."
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.
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.
[deleted]
I call that dependency-oriented-program-engineering (DOPE)
“Slave is an Ephebian word. In Om we have no word for slave,” said Vorbis. “So I understand,” said the Tyrant. “I imagine that fish have no word for water.”
Terry Pratchett
Terry Pratchett
I understand the point you’re getting at, but humans have a word for air? If fish really did have language, they would at least have a word for air, which would mean that they would also probably have a word for not-air: i.e water.
From Wikipedia
>The opposite predisposition is sometimes called "proudly found elsewhere" (PFE) or "invented elsewhere".
>The opposite predisposition is sometimes called "proudly found elsewhere" (PFE) or "invented elsewhere".
Never Invented Here. Or maybe duct-tape programming.
I've heard HackerNews call it Never Invented Here.
IMHO, the only valid reason for "roll your own" is if the application needs 50x+ performance than what would be possible using existing solutions (as is the case described in this blog post). Otherwise follow the rules:
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
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
> NIH highlights situations where engineers side with reinventing the wheel due to a belief that building technology in-house will be better, quicker and cheaper than using an existing solution
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.
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.
> due to an uncontrollable urge that building technology in-house will be more fun, more interesting, more pleasing than using an existing solution
Indeed, retention is valuable.
Indeed, retention is valuable.
The article mentions:
> 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.
> 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.
[deleted]
To explain the bias around NIH, I use the D and D analogy of “pursued by people longer on intelligence than wisdom”
"Somebody else has had this problem."
As a marketing consultant, my biggest advice to clients is to never, ever build anything custom. Use Zapier to connect things, Segment to manage data flow, Shopify/Weebly to build the site, use Sumo to test site changes, etc. Building things custom just delays projects so much, especially in marketing where you don't even know if a project will achieve the goals you want.
How many bugs do fix by removing complexity that is unnecessary for your special case?