Not Invented here

I wanted to write this week about the not invented here syndrome (NIH from now on). When I was preparing the materials and the readings I stumbled upon Quincy Larson’s great post How to stand on the shoulders of giants. I suggest you read his post. However, I would like to look a bit around how to identify this syndrome and how to cure it.

There are many reasons why not to develop something. And there are many reasons to do. The main question is whether we pick the correct ones when we make the decision. Basically looking at the wider question of build or buy can help make the right decision. When you get to the point you need to make the decision, having a pro and against list for developing in-house or using third party, open source or not should be considered based on objectives, not subjective found in the list in the image above.

Identifying the syndrome

The first step before you identify a NIH is not to identify it. I mean, you should first assume good faith, and not jump to any conclusion. Look at the situation(s) that led you to think there is a NIH issue at hand, and ask the involved person why they made the decision they made. Most people, most of the time will give you valid reasons you have failed to notice. After you have got the response, and if you see a repeated pattern of decisions that fall into the bingo above you have a NIH problem.

The problem can be on any level, from yourself (see Quincy’s post above) to a whole team, department or even organization or company. The ability to cure it highly depends on the level the issue is manifested at.

Curing the syndrome

In order to cure NIH, some drastic actions are usually required. If the issue is limited to one person, any managerial technique from talking to the person up to firing them might do. But the main, and most useful in my opinion, is surfacing it so the person can be aware of it and fix it if they desire. If they don’t, then you might need to take further actions.

Dealing with NIH at higher levels of organizations from a team level and above is much more complicated and will require establishing processes to overcome the automatic “We will do it, from scratch” reaction. For instance, having a process to describe available software solving the current business need as part of the problem description might help.

When NIH occurs at an entire department or even the whole company, accepting the issue might be the only way forward at times. However, since I think we should not give up on issues but rather try and help fixing them, I would suggest a possible way would be to try and illustrate the costs of adopting such a behavior. Science and technology only advance as we all stand on the shoulders of giants. Avoiding their work and starting all from scratch would lead us back quite a lot and will cost a lot.

Here is a dilbert to close with a smile:

Dilbert Comic Strip on 2014-08-12 | Dilbert by Scott Adams
_Dilbert: The project I inherited has weak code. I need to rewrite it from scratch. Boss: Will there ever be an engineer…_dilbert.com