(A draft/work in progress discussion)

Using patterns, for the sake of patterns, or trying to fit every problem into a pattern, or into a single language, or into a single solution, is not a good idea. I remember in one of my first jobs, my engineer team warning against seeing every problem being solved by C.

One that particularly annoys me is the automatic rejection of things developed in house, spouting the Not Invented Here.

Interestingly, my experience with the quote and implementation of Not Invented Here has not been from the development teams. But I will come back to that...

Now let me clear. The idea behind NIH (Not Invented Here) is that a technology team would refuse to use products not invented by their team. However, in practice, that is not how the phrase is used.

Loosing the driving force

One of the main good reasons to look at other applications and teams outside of your own is that you may have a single driving force. I have seen many cases within schools, using a great setup of Moodle as an example of why you don't need to have a central service providing lesser products. Then that teacher left, leaving the system to inevitably fall over.

Always trust the consultant

Have you ever left a company and come back as a consultant. It is amazing how many people I talk to, whom have been in that position, who leave the company that they could not get change into, come back to consult and the change is implemented immediately.

Companies, especially small to medium sized companies in Australia, tend to ignore their inhouse experts. They assume that outside people are more advanced.


Large scale user system

Once when I ran a team of over 20 developers, we moved to a system which put the control of features, bugs to be fixed etc, outside the team. We put in a testing team that had all the control of acceptance, and management team of customers that had all the control of the customer acceptance. We put in contracts that put the customer in control of what is accepted.

Sounds reasonable right? But let me put it another way. Do you have control over when Telstra upgrades the phone system?

In the end, we spent endless amounts of time convincing people internally to replace an antiquated system (either externally developed, or internally) with a far better (usually open source) alternative. We would spend ages showing the total cost would be reduced on bugs and features by not maintaining our own. Of course there is cost in doing so, usually upfront. Patching a system is generally cheaper. Other priorities would get in the way, and we would be stuck with the old system.

So how is this NIH ? When we, as the expert internal team, asked for a change, we would have to prove it from first principles and financially that it was worth while.

But when other teams: specifically management teams and system administration teams, wanted to replace a system, even if it was core to our product, and would cost more to port to than the existing, no research was needed. All they had to say was "Not Invented Here Syndrome" and management team would ignore the development team research.

Hospital training

A hospital training system, been developed mostly resources, but some PHP back end to login and record results, was replaced with a commercial product built on top of Sharepoint. The idea of course is to provide a common system across the hospital. No work or research was done into the existing system, it was automatically dismissed.

The end result was that trying to move their training material into the Power Point controlled system actually took more time, per resource, than the development time of the original system.

Worse still, it didn't integrate with the login system of the hospital. There was no way of tracking the nurses progress.

Club database and website

A recent club database and website that has been worked on for 4 years had a reliability issue. Ended up being sorted as a resource being accessed would not let go locks, once more than about 10 of these had locks, other processes were blocked.

So the new administration of the club decided to replace the 4 years of development with a wordpress site.

During the move it was often asked: What sort of publishing system do you use here. The answer would be something like "a modified version of oddmuse" or similar.

The long term and slow development of this system was moving to replace a competition system, a publishing system (news letters etc), a social site (mostly for members), a club wiki, the club members database (currently automatically imported data from the old system), management of email lists, document management system, booking system, TODO list and lots more.


  • NIH is real, it should not be ignored
  • NIH is a team rejecting external just because it is external
  • NIH as used in practice is not usually NIH, but an excuse or misunderstanding
  • Consultants are listened to rather than your own, trusted, long term invested resources internally.

References (not yet reviewed)