It is something that we encounter frequently. In fact, many of us suffer from this syndrome without being aware. Not sure if you already infected? Take this simple test:

Go back and try to remember when was the last time you woke up one day with a brilliant idea: you were going to build “wheel 2.0”! While innovation is our driving force, try to remember if before you started to work on your new wheel, you stopped and asked yourself one simple question: “Why?”

[Note: “Why try to fix something that is not broken?”]

The Classic IIS Affect

Let’s start with a classic example. On a recent project that I’ve been working on, we had to develop a trading module that books and save trades into a database. Given this short description, one would expect that we would use one of the commercial databases platforms, such as Oracle, Microsoft SQL Server or Sybase , which are already supported by hundreds (if not thousands) of software components to help developers to easily work with those databases. Moreover, there are plenty of Add-ons components that were built on top of those databases (by companies who built their entire businesses around it) to support additional functionalities such as versioning, multi-tier transactions and others.

However, we weren’t that fortunate this time…

Instead, we had to work with an in-house proprietary database that was developed for a specific purpose (which is questionable too) and later on was expanded to support other applications’ requirements. This is exactly the point where ineffective innovation comes into place.

Let me give you a short background:

This database was an idea of couple of people who decided to build their own “signature” database without considering alternatives, long-term effects, future cost and others. As long as this database was used at a small scale, where maybe a handful of developers were using it, it was easy to work with and to make appropriate adjustments to accommodate additional requirements by the developers.

Up to this point, its all seems fair. The “innovators” were happy with their own “signature” database and the developers were happy with their own “its-exactly-what-I-need” database. However, this was the tipping point of this innovation and it should have remained within the boundaries of this small team.

UNFORTUNATELY, given their relative success, those guys decided to expand the use of this propriety database and share it with more teams across different groups (and some, like my team, had no choice but to take it by default). That was the point where this small “good-looking” snowball started to roll down the “efficiency” hill.

Here are only few of the problems that we all started to encounter:

• No documentation – There was no place where you could read how to use this database.
• Limited and inconsistent API across multiple languages – Java developers had threefold more functionalities and worked in a completely different mode than .NET developers.
• There was almost no support at all – some of the developers that built the database or the API layers left or moved to another projects.
• All the “innovators” were already working in a different department on a completely different product.

The result: Long and extremely expensive project.

Wait! There is more.

Due to the dependency of many teams on this database, this inefficient innovation will only grow and will increase the cost of future projects significantly.

[Note: of course, none of the “innovators” realized what they did; they were all working on other projects already].

This classic example is only one out of many that I’ve encounter over the years. I’m sure that each one of us has similar skeleton hidden in his own “D” drive (you are more than welcome to share those with us).

Reinventing the wheel – is it a good thing?

Don’t get me wrong. Without people who woke up one day with an innovative spirit to make a change, we would not be living in such a rich “gadgety” / service-oriented environment that we live in today. Simple services we use today are the fruits of those innovators who took nothing for granted and had the ambition to improve the existing. Take Google, which revolutionized the online search, or FaceBook, an even more recent example, for reinventing social networking, as the two huge successes stories.

However, this problem is not with those types of innovators. The problem is with those “innovators” (with all do respect, I have added the double quote) that some “wheel” didn’t fit exactly to their project needs, so they decided to build a new one. While being easy on the trigger, they often lack the skill of evaluating what would be the REAL consequence of designing, building and maintaining a “wheel 2.0” or what could have been changed in their project in order to accommodate “wheel 1.0”.

In my next post, I will analyze the reasons that often starts the Inefficient Innovation Syndrome and what can we [try to] do to avoid it. Whether it’s our own idea or a process that is running within your organization, a small change can lead to great consequences…