Not invented here (NIH) is the philosophical principle of not using third party solutions to a problem because of their external origins. It is usually employed in favor of employer’s own solution to a given problem.
For a couple of years now, every now and then, article is written explaining why NIH syndrome is bad and how, although we’re all guilty of it occasionally, we should fight it. I’m about to offer a much needed opposite perspective.
If we understand NIH as being tendency towards constantly Reinventing the Wheel (RTW), with a psychological background, then it necessarily follows, that NIH is bad. No argument there.
Unfortunately NIH and Reinventing the Wheel (RTW) are being often used interchangeably, and the amount of bad publicity surrounding NIH, is being broadly applied to all circumstances. Problem is further emphasized by common tendency of software development community to, as it often happens, distort and exaggerate the initial problem, in this case leaving us with a dysfunctional social phenomenon of its own, which I’ll call simply RTW phobia.
The definition of RTW phobia is simply a fear of recreating an already existing solution. More directly, in software development, sufferer RTW phobia will under no circumstances prefer own (or in house) solution, if any external solution is available. Such person will insist on implementing existing solution, even if such implementation will be less time efficient (in a long and/or short run) and will be technically inferior.
RTW phobia and NIS Syndrome in a Business Environment
I strongly believe that when an external solution, which is fitting the requirements, exists we should use it; on the other hand, when no such solution is available we shouldn’t try to force it. There’s a degree of subjectivity in it, and I suppose making the right choice is the difference between an experienced and a novice project manager/developer. A novice will take NIS Syndrome as one of the Anti-patterns, and hence absolutely bad, and he’ll fight against it rigorously. For example, he’ll be more than ready to pull in a whole Twitter Bootstrap for a specific simple control to work, just to avoid a little bit of RTW.
We must understand that RTW can be a necessary and a productive choice. We might choose to RTW when an existing solution:
- has a restrictive/uncommon license,
- is not maintained anymore, is in early beta or has a small amount of active developers,
- lack big part of essential functionality,
- has unstable community or a developer, who breaks backwards compatibility regularly,
- is poorly documented,
- is buggy or poorly programed,
- raises security concerns,
- pull in too many of 3rd party dependencies (relative to what its task is),
- is too big or complex for your needs.
The last two points are a topic on its own; I’m a big fan of minimalism (YAGNI, KISS), and I believe that an idea to better take more in case we’ll need it later is a destructive one. It’s not an argument against RTW, but rather an reflection of poor planning and/or more importantly, lack of modularity of a given system.
NIS Syndrome stands at the opposite side of the RTW phobia and both are equality harmful and should be avoided. The middle path, as usually, is the right one.
RTW in Open Source Software
Open Source Software (OSS) is a different story, as a majority of work is done by volunteers. To dictate whether an individual should or shouldn’t RTW in OSS goes against common sense, it’s in a way like dictating whether and where should an individual go to vacation and which books he should or shouldn’t read.
Anyone who’s working on an existing OSS project(s) deserves gratitude and appreciation; in similar manner, people who decide to work on their own, even if that means RTW, should be encourage rather than shamed for it. Practice of discouraging RTW in OSS, is harmful and is especially surprising when it happens in GNU/Linux community, which philosophically is very in favor of freedom, which depends on choice, which in turn depends on variety of software, even if (or especially if) functionally very similar, to choose from.
There’s a personal benefit individual derive from RTW, and it differs from when contributing to an existing project, although obviously, both are satisfying.
I understand the counter argument, which is: we should focus on one thing and do it right, rather than constantly (re)invent, and hence being left with multiple unfinished and unpolished solutions. But perhaps we should see OSS more as an evolutionary process, hence great diversity and indeed constant RTW is essential part of the growth and needed for survival.
Either way, a desire an individual has to RTW, might be understood as a natural tendency towards creativity; perhaps we could go a step further, and state that those who’re more artistic in general, are more inclined to RTW; but obviously this is merely an assertion and I have no idea if there’s something behind it.
Beside creative expression, RTW offers a chance to learn new things in a really fun and practical way, it offers an insight into existing projects of same type, because sooner or latter when developing own version of a particular software, a developer will come across some of the challenges big projects were (or are) facing. At that point he can use those projects to learn from, or find his own creative solution which, if it’s well done, can help other projects.
To conclude, I believe we have nothing to loose if we encourage people who’re inclined to (re)invent, but we have a lot to gain.