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
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
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.