The ideology of Not Invented Here (NIH) occurs when a business (or team, or any group of people) decide that the things they created or that their business has created are more valuable than things created elsewhere.
In essence, this team has made the decision that, since they are the ones who work at this place, the stuff they build will naturally be more suited to solving their types of problems than would other solutions.
To an extent, this ideology is understandable. Where it becomes dangerous, however, is when teams make the leap from "our stuff is more likely to solve our problems" to "only our stuff can solve our problems," a leap which is surprisingly easy to make.
Or, at least, easier than this:
The Rundown
- Name: Not Invented Here (NIH)
- Summary: Occurs when a team decides to use only their own custom solutions instead of looking for others which may solve a problem more efficiently or correctly.
- Type: Management
- Common? Let's make our own, and we'll find out...
A Quick Note
We're using the term "Not Invented Here" to mean situations in which management decides to use only homegrown software despite better, cheaper, or more thorough solutions already existing (and known to the manager or their team). In other words, Not Invented Here is only an anti-pattern when it works to the detriment of the manager and team in question.
Tell Me a Story!
Lots of modern companies are software companies, but software isn't their primary business (that includes my current employer). Consequently we mid-sized-business developers often need to implement solutions that are almost, but not quite, like other well-known software platforms. My particular business has a do-it-yourself company culture that, until very recently, permeated everything we ever did, including software development.
Case in point: an aborted custom system that I'm going to refer to as CCAD (Custom Chat Application Debacle).
My company has two separate chat systems. One we use for customer who wish to talk to the company, ask questions about our services, get assistance, etc. The other is used by employees of this company to talk to each other. They are both chat applications, and on first glance they seem very similar to one another.
Well, software developers hate redundancy, so our director of IT instructed us to implement a new chat system that would envelop the two old systems in a single, usable package.
Did you catch the word "implement"? We were supposed to make our own custom chat system. And guess who was gonna be the lead developer on that project? Me.
So I got my team working on the CCAD. To make a long story short, we spent three months off and on researching this project, developing prototypes. At the end we were told "very good, nice job, but we're gonna go a different direction" and they promptly entered a contract with a chat provider to implement these systems.
This was the moment, the eureka moment, when my company decided that maybe using software that was not invented here actually did work. And I was incredibly glad they did.
Chat is a solved problem. People know what a chat system is. My company doesn't do software as a business, it does physical services, and we don't need to implement our own custom, buggy, terrible to maintain chat service when someone else has their own. CCAD should have never happened, and would never have succeeded. I was relieved the executives figured this out eventually.
But I'm a lucky one. There are many companies who fall prey to Not Invented Here, and are still fighting it off.
Strategies to Solve
I'll be frank: unless you are in a managerial position, getting any particular organization to abandon Not Invented Here is akin to bailing out the Titanic with a spoon. But let's say you are a developer at one of these companies that is afflicted with NIH-syndrome. Is there anything you can do?
First, you can promote ownership. Not of code; rather, ownership of solutions. Have your best teammates take a project that needs to be done, and let them come up with solutions for it (and, crucially, let them implement said solutions). By owning a solution, people will come to know the ins and outs of that solution, and where it can be improved. People who are in charge of solving problems will often use the best solution, regardless of where it originated from.
Second, advocate for the idea of "you are not your code". I find that a lot of people cling to solutions which they themselves have created or vetted, and over time, these solutions tend toward custom-built projects that solve an increasingly narrow set of problems. Without correction, this kind of environment absolutely breeds NIH. Remind your teammates that, because they are not their code, they are free to change everything, find better solutions, break things. Devs must be free to make changes.
Third, and if all else fails, and the company will never let go of their NIH syndrome, leave. Just leave. Nothing you do will make a difference, and your skills will stagnate. Nothing kills careers faster than stagnation.
Summary
Not Invented Here is a pernicious management anti-pattern, one in which the necessary solution is often also the problem: the management themselves. As a developer, your best shot is to promote ownership of and separation from your code, so that you and your teammates have the necessary distance to look at code critically and see how, where, and precisely why it sucks, and make changes accordingly.
Do you know of a company who fell prey to NIH? Can you tell me about it, even in general terms? Let me know in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
