Should You Invent a New Wheel?
It has become a conventional wisdom in software development that you should NOT re-invent a new wheel – reuse an existing one instead. There are many compelling cases in which re-inventing wheels had caused catastrophic failures as described in Joel’s article Things You Shoud Never Do (Great article BTW). One famous example there was the NetScape’s loss to Microsoft in the browser war more than a decade ago.
Nothing is absolute in software however. You can find opposite cases like Microsoft’s successful re-inventing Windows from Window 95 to Windows XP. Actually in a longer term, you cannot stick with a wheel forever; otherwise we are still using wooden wheels in the pre-industrial age. Same is true for software.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
I think the question is really not whether to invent a new wheel, but when. In other words, in which condition should you consider re-invent a new wheel?
Technical Reasons for New Wheels
Given the potential risks of re-inventing wheels, you’ve got to have a compelling reason. In the end, your return should justify the investment and efforts. You should NEVER invent a new wheel for the sake of being new.
You can analyze the ROI on many different levels and aspects. From the view of software development, I think these could be compelling reasons for you to invent a new wheel:
- New features. Not all new features need new wheels, but those disruptive ones. Eclipse project for example is a new “wheel” from the VisualAge family of products with a disruptive feature called “extensibility.” It’s then designed to be a platform, to which you can design various language IDEs as plug-ins.
- Architectural bugs. Essentially these are architectural flaws that prevent you from moving forward. Instead of changing the current one, you’d better off re-writing everything simply because it’s faster.
- Scalability. As pointed out by Jeff Dean, “Design for growth but don’t design to scale infinitely. You can shoot for 5 to 10 time growth. If a system grows 1,000 times, it requires rethinking and rewriting.” When the demand grows dramatically, you have no choice but to invent a new wheel.
- Performance. With an existing “wheel,” you can only achieve some improvement with tuning and optimization, but mostly not too much. In the open source VI Java API, I created a new Just Enough Web Service Engine to replace Apache AXIS and achieved 10+ times performance gain.
- Portability. Your system runs only on Windows for example, and your customers want it on Linux for example. Ideally, you just port your code. Optionally you can switch to Java for ultimate portability.
- Legal. There are occasional cases in which you cannot accept the license agreements of existing wheel. That leaves you with no choice but to rewrite a new one. In my opinion, this should be the least reason.
Business wise, it’s always hard to get a right timing for reinventing a wheel because markets are always moving fast. If you don’t move, others pass on you. You can for sure take dual development approach as Microsoft did with Windows 95 and Window XP. This of course requires double investments, half of which is soon thrown away.
Also, when you dominate/monopoly a market, you have a much better chance to reinvent and succeed. This is really nice but hard to achieve condition.
What to Watch?
When you decide to create a new wheel, you should be careful on how. Here are several tips:
- Strive to keep the external interfaces intact, so that your new wheel can get along with others in day one. When no one needs to change anything, it’s much easier to be adopted. Sometimes it’s impossible. Still minimize it.
- Pick appropriate working pieces from existing system. At least the code from existing system is fully tested. If you can leverage it in some way, it’s great. You got to make a judgment which piece is a good fit and which is not.
- Do not drop features. This will only make customers unhappy and leave room for your competitors.
- Take an incremental approach in the process.