Not Invented Here Syndrome

If you haven’t heard of it before, ”not invented syndrome” is when an organisation develops a custom solution to a problem that has been solved before. I also extend it to when an organisation creates a completely custom solution for an issue that hasn’t necessarily been solved before, but a very similar problem has been solved, and the available solution could easily be extended.

# How does it occur?

For the purposes of this article I’ll use a fictitious company called “Bespoke Solutions”, and the example requirement is to get attendees to checkin at a meetup and to supply their email address if it isn’t already on file. Using this example we can quickly discount Meetup’s built-in attendance feature as it doesn’t have an option for check-ins, instead it only offers the ability to mark someone as a no-show. A quick search on the various app stores shows there are some products to manage checkins, some are free, some are paid; but none of them seem to have the ability to collect email addresses.

At this point the product team at Bespoke Solutions starts designing a custom system to integrate with meetup, display the potential attendees and mark them as attending. As attendees verify their attendance the system checks if their email address is on file and prompts for it if it is not. At the end of the meetup the organiser is able to mark all remaining attendees as no shows.

The product team provides the specifications to the developers; one of the developers regularly attends meetups and has seen a checkin system being used before. The developer quickly realised that most of the work has been completed by someone else, and is able to rapidly find the publicly available source code for an app that handles the attendance. The developer recommends that the designs be modified to use the existing system and just add the email collection functionality.

At this time Bespoke Solutions’ not invented here syndrome kicks in and the developer is told to custom develop the entire solution. Sometimes the justification for this is “what if the existing product has a bug”, or “the designs don’t match what we want”, perhaps it’s “but we won’t own the intellectual property”; there’s any number of reasons that can be used for not extending an existing base, but most of them can easily be worked around.

After several sprints of work, the developer finally delivers the product, it does exactly what is requested. The developer is happy to have finished the work, the product team is happy they’ve got the solution developed, but the customer has already moved on; one f their staff found the open source solution that did the attendance and in a few hours added the email collection functionality, thy and be been using it for a month already.

This is just a small example, but what if it were a larger system, maybe a workflow system with multiple triggers, decisions, functions and endpoints. There are plenty of solutions out there that will implement a standard workflow language called BPMN, they may need some customisation to add the required functionality, but more than 1 of them will be 90% feature complete. Far too often I’ve seen organisations decide these are too complex for their needs, or miss a few key requirements, and so they develop a custom solution. Over time these custom solutions invariably become a bottleneck in the system, or are extended to the point they implement the complex system (usually in a less effective and highly inefficient way). The total cost of ownership of the solution could have been significantly reduced by restricting functionality on a complex solution, or by adding some minor functionality to an existing solution.

# How can it be avoided?

It’s easy to avoid not invented here syndrome, but it’s hard to convince decision makers its the right thing to do.

To avoid it, simple look for alternatives early in the planning process; recognise when its more efficient to restrict an existing, complex system; and be willing to add functionality to existing systems that don’t meet your needs.

Helping decision makers to understand the benefits of avoiding not invented here syndrome is more complex. It requires humility from developers to make sure decision makers are aware that internally produced code is just as likely (if not more so) to contain bugs than open source software; it requires the company to take pride in developing the best, cheapest and most effective solution rather than taking pride in custom development; it takes early consultation between decision makers, product and developers to design the most effective solution.

# What are the benefits?

The biggest benefit of avoiding not invented here syndrome is the reduction in development costs, both in the short term and long term. Additional to this, any fixes applied to the original source software can be applied to the new product and improve security or increase reliability and feature availability. Finally, the reduction in development time and potential increase in functionality means the organisation can deliver more value to the business and customers in a short time frame, whether that be in other projects of extending the capabilities of the current project.