Thoughts on Developers and Not Invented Here Syndrome
I'm often asked to build applications which are similar to existing applications built by third parties. This article will explore the Not Invented Here Syndrome and will try to answer the question of when to build and when to use existing solutions.
The Not Invented Here Syndrome
In software development, the Not Invented Here Syndrome refers to situations where companies or development teams build applications which replicate the functionality of already existing applications. This is not limited to building whole applications, but also to building frameworks or modules which perform basic functionality, such as authentication.
Common "Justifications" of Not Invented Here Syndrome
There are many reasons used to justify building applications which replicate already existing applications. Some of these are:
- The existing application doesn't have feature X which is important
- Dislike of existing application's user experience
- The license for the application is too expensive
You might have encountered any of these in your software development career. I have encountered all three, and there have been instances where I ended up building something from scratch. In some cases, the application that I built ended up not being used. In other cases, the cost of development and maintenance ended up being more than the purchase of a license for the alternative.
When to Build and When to Buy
I'm not saying that building something from scratch is never a good option. However, you should make a thorough investigation to identify whether to build or buy.
Build a Business Case
As a minimum, you should have a project sponsor pushing the software project. Without a sponsor pushing for the usage of the software, you risk building something that will never be used. Make sure that the sponsor is someone who can take decisions in your company.
Once you have a sponsor, you need to create a good business case for the application. You need to consider the cost of development of the application when comparing to an existing software package. Make sure you include costs for maintenance and administration of both the custom build and the package. This will give you an idea of which provides the better return on investment.
If you have a huge pipeline of work (who of us doesn't have a huge pipeline?), you need to consider that using a package could allow you to build some other important application by releasing your time.
When to Build
Some of the valid reasons to build a custom application are:
- No off-the-shelf applications exist
- Is significantly cheaper than buying
- Will give you a competitive advantage
You should definitely build the software yourself if no alternative application exists. The same applies if the business case results in significant savings if you build yourself.
You should also build the custom software if this will result in a competitive advantage against your competitors. Balancing the financial return versus the cost of building and running the software is critical. You don't want to end up running out of funds trying to build something which gives you a competitive advantage.
When to Avoid Building
Avoid building custom software if you can get it cheaper off-the-shelf or if you do not need the software to gain a competitive advantage.
In addition, you need to be extra careful about re-inventing the wheel in certain aspects of software development. I've encountered developers who have attempted to build encryption schemes, authentication services and other critical components.
You should leave development in these critical areas to experts. By way of an example, read this post by Troy Hunt on setting up a secure account management feature on a website.
Conclusion
In this article, I've explored the Not Invented Here Syndrome and provided some guidance on when to build and when to buy. One key takeaway should be that you need to give careful consideration of the pros and cons of your specific case.