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.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Timing

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:

  1. 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.
  2. 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.
  3. Do not drop features. This will only make customers unhappy and leave room for your competitors.
  4. Take an incremental approach in the process.

This entry was posted in Software Development and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  • NEED HELP?


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.