Diagnosis — Not Implemented Here syndrome

A developer, architect or manager with Not Implemented Here syndrome has lost touch with reality. It shows up as a compulsive desire to implement everything ourselves, because we’re convinced of the following.

• It’s simple
• We’ll have complete control
• We’ll write it to fit our exact needs
• Nobody can do it as well as we can

So developers write their own transaction managers, MVC implementations and ORM frameworks. In all my time in the circus we call development, I’ve never seen Not Implemented Here deliver benefits that substantially outweighed the cost of building the thing.

My experience with Not Implemented Here

• It looked simple at first, but somehow it’s grown into a monster
• We control all the code, but nobody actually understands it anymore
• Our needs have changed over time, and the simple solution no longer does the job
• It’s our own solution, so we have no documentation. That’s fine, anyone can just read the code

Two other problems affect most homegrown solutions, and I’ll go into those in more detail. One is performance. Our own solutions generally don’t scale, so we try everything we can to help them along. We add caches and try all sorts of dodgy tricks. The result is a lot more error-prone hacks in code nobody understands anymore.

The other is defects. We’re the only ones using our own implementations and frameworks, so we don’t get much feedback. Instead, we struggle through four iterations or so to reach production quality. By then about two developers in the company understand the code, one on the way out and the other off sick.

How do we get out of this? With difficulty, unless developers acknowledge the downsides of Not Implemented Here. Contributing to open-source projects is a good way forward. When something doesn’t suit us or falls short, we can help change it directly and will probably get plenty of feedback. Get rid of Not Implemented Here and you’ll save a lot of development time and resources.

• Wikipedia — Not Invented Here