Reinventing The Wheel - An Age-Old Anti-Pattern

It is hard to go through life without being warned against reinventing the wheel at some point.  This recommendation is a general warning to avoid duplicating effort where possible.  Thus, we have an easy to understand anti-pattern.  On the other hand, we should look deeper to determine whether we are avoiding an anti-pattern.

Defining the Reinventing The Wheel Anti-Pattern

The DevIQ site has a simple definition and problem description that serve as an excellent basis for our discussion. [Click Here to See The Page]

"It’s common for software developers and some organizations to prefer to write something they may need for a given project themselves, rather than using an available open source or commercial offering.  Generally, it’s best to avoid this urge unless the feature or tool in question is a core part of the product being delivered."

Note the use of the word "generally" at the start of that second sentence.  There are some great reasons to tackle a problem from scratch instead of going with known solutions.  You might even be avoiding the related "reinventing the square wheel" anti-pattern where someone starts with a broken solution and tries to fix it.

Have a Reason

With strong reasons for and against reinventing the wheel, there should be an intentional approach to implementation.  The first step is to recognize what has been done before.  Once you have noted those situations, then proceed to decide whether or not you should use those solutions.  The easiest way to avoid this as an anti-pattern is to have a good reason for the approach you selected.

Lost Opportunities

A lot of developers lean towards reinventing the wheel as opposed to re-using the work of others.  They recite reasons to avoid using that prior solution along the lines of time to ramp-up or understand the work of others.  While these may be valid reasons, the value of reuse should not be glossed over.  Simple things like testing and quality are profoundly impacted by starting from scratch.  Instead, use a solution others created and tested.  Gain from their experience and efforts.  There is also an often underestimated value of using solutions that have been tested in multiple environments and contexts.  There more you stretch a solution and validate it, the higher the quality it has in any situation.