Reinventing the Square Wheel is a methodological software anti-pattern in which an engineering team attempts to reinvent a system or tool that already exists and works properly, but does so poorly, so that the result is worse than the original.
This is usually due to an incomplete understanding of what the original item does.
This pattern is incredibly fun to talk about because the results are often hilariously wrong. This is best illustrated by a venerable cartoon that I'm sure you've seen before, and if you haven't, you're welcome.
The solution to avoid reinventing the square wheel is at least 80 years old, and comes to us courtesy of a paradoxical theologian and all-around fun guy... but we'll get to that.
The Rundown
- Name: Reinventing the Square Wheel
- Summary: Attempting to rewrite or re-engineer a system which already works, and ending up with a poor imitation of the original system.
- Type: Methodological
- Common?: googles for synonyms to "yes"
What This Anti-Pattern Isn't
This anti-pattern is not the same as just reinventing the wheel. I'm of the opinion that reinventing the wheel is a good thought process, provided your goal is to learn about wheels.
Reinventing the square wheel, however, is universally bad, because it implies you ended up with a worse product than you started with.
Tell Me a Story!
I have this idea that all developers have been involved with this kind of project at one time or another, and anyone who hasn't is lying. This is a human anti-pattern just as much as it is a technical anti-pattern, and it has to do with how people generally think they are smarter than they actually are.
Problem is, that includes me.
Our company's cafe needed a point-of-sale (POS) system. This is the kind of system that the cashiers use to help customers pay for their meals and snacks. Because we're a do-it-yourself kind of company, the task to develop such a point-of-sale fell to my team.
And I, in my hubris, was sure, absolutely sure, that we'd have it done in four months. It couldn't be that hard.
Future me would like to slap past me in the face. Of course this was hard. It was so hard that entire companies made a business out of creating and selling these kinds of POS systems (and, let's be clear, if my system had been allowed to proceed, it would have a been a POS in more ways than one).
We spent nine months developing our POS and it could only do half of what our current analog system could do (read: pen and paper and knowledge). So we bought another company's product and the cafe runs with this product right now.
I wanted to reinvent the wheel. A point-of-sale system is a solved problem, especially for something as simple as this single cafe. I wanted that knowledge. I ended up with a useless system and nine months of wasted time.
Strategies to Solve
The simplest way to ensure that you will not ever have the "reinventing the square wheel" problem is to not try to reinvent a wheel. But that's no fun! So what can we developers do to avoid rewriting and ending up with a worse product?
The solution comes to us by way of the paradoxical theologian I mentioned, G. K. Chesterton. He told a story (that I've written about before) which went like this:
There is a man walking down a country lane. He comes across a fence. To his mind, the fence is not holding anything, or doing anything of note. He decides that it is useless and wants to tear it down.
He goes to the town council, and tells them his plan. The town council leader denies his request to tear down the fence. He tells the man: "Go away and think for a while. If you can determine a reason as to why the fence is here, why it might be at this place, then maybe we will allow you to demolish it."
Thus, we get the modern formulation of an adage known as Chesterton's Fence:
"Reforms should not be made until the reasoning behind the current state of affairs is understood."
Respecting Chesterton's Fence is the key to solving the Reinventing the Square Wheel problem. As a developer understands more of the original tool to know how to make it better, he is increasingly unlikely to make it worse when it gets rewritten. The solution, in short, is domain knowledge. The more you have, the less likely you are to screw up.
Summary
Reinventing the square wheel happens when a developer or team, with insufficient knowledge of a product, attempt to recreate that product, but do so poorly enough that the result is worse than the original. If you want a real-world analog to this software anti-pattern, go read about the New Coke debacle. It's fascinating stuff.
Do you have any other examples of the "reinventing the square wheel" problem? Maybe even a time when you fell victim to it? Did Chesterton's Fence help you out in some project? I'd like to know about it. Share in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
