Not Invented Here Syndrome Explained
Not Invented Here Syndrome (NIHS) is when a developer rejects external solutions in favor of internally developed solutions. I’ve seen teams build everything from scratch, even custom communication protocols, object-relational mappers (O/RM), continuous integration systems, and so on. I’ve even seen projects where the developers built a Relational Database Management System (RDBMS) on top of SQL Server! So, instead of using SQL Server Management Studio to design their tables, they built an MS Access Application to create tables and generate deployment scripts! They even went to the extreme of redefining primary data types such as number and Boolean.
My super-duper workflow engine
A few years ago, I worked on a project where we needed a workflow engine. At first, I thought about using MS Workflow Foundation (WF), since I develop mostly in the .NET space. But then I thought about how I had very little time to spend on learning all the capabilities of WF. I thought WF had a lot more capabilities than we needed. So I thought it would be more productive to write my own workflow engine. And being an object-oriented analysis and design geek, I got really excited about designing some super-duper workflow engine that could later be extended. I wrote lots of unit tests for it to make sure it worked reliably. Guess what happened? I spent nearly two weeks on designing, implementing and stabilizing my custom workflow engine. Later, I realized I could have spent only one day reading some tutorials to quickly learn MS Workflow Foundation. I could have saved myself 13 days and delivered the project a lot faster. That aside, do you want to know what happened in the end? I didn’t get paid a penny for those 14 days designing my super-duper workflow engine. The funders of the project had a very limited budget and they couldn’t afford it, so they stopped the project!
What problem are you solving?
If you’ve fallen into this trap due to your passion for programming, you’ll need to realize that this is one of your biggest productivity killers. If your job is to build an order processing application, writing a custom object-relational mapper should not be your focus. It would be better to utilize an existing O/RM others have developed. If you spend your time building all those capabilities, all of a sudden your focus changes from developing a reliable, state-of-the-art order processing application to something else. You have to switch between different domains all the time, which affects the overall quality of your solution. I guarantee, if that’s how you work, neither your order processing application nor your custom O/RM will be quality products. They will be average at best.
Some contractors see this as a way to secure their jobs. They like to make things more complex to ensure that they won’t be replaced. Plus, they feel better about themselves because they think they have implemented something very complicated. As I mentioned elsewhere, Leonardo Da Vinci said, “Simplicity is the ultimate sophistication.” Think about it. One can claim they have done something sophisticated only when they’ve thought of all the complex solutions and come up with a simple, elegant, clean solution that no one else could have thought of. THAT is the engineering mindset.
So, do programmers who advocate complexity and reinvent the wheel make more money? I don’t think so! By making things complex, they decrease their productivity, which means that instead of delivering a bunch of capabilities to their client within one month, it may take them three months to do so. That means their clients won’t be happy. Chances are they may run out of funds or even decide to close their business. That means the end of contracts for those developers! Do you think that clients will recommend those developers to other potential clients? What could they say other than everything took a long time to deliver and they ran out of money?
Let’s say you know nothing about the mechanics of your car. Something is wrong with your car and you take it to a mechanic for service. He gives you a quote of $2000 with a delivery time of three days. You take it to another mechanic and he tells you he can fix it in a day for only $500. Which mechanic would you choose?
Think from the perspective of your clients. If you make them happy and successful, they will always come back to you for more work. The world doesn’t stop! Software applications need more and more capabilities. Requirements change and evolve. You’ll never be out of a job if you deliver quality solutions within a reasonable time at a reasonable cost.
So, don’t reinvent the wheel! Utilize what others have done. You’ll be 10 times more productive and you’ll build better relationships with your bosses or clients. You’ll get more credibility, which means you’ll have a better future.