I’ve got a few reasons for “reinventing the wheel”, some personal and some practical:
- I’m curious and want to know how things really work.
- I like DIY from scratch projects.
- Bottom-up learning is valuable.
- There are things that are fundamentally flawed and need to be done again from scratch.
- Existing tools don’t always match the criteria for your specific task and/or introduce too much complexity.
- Because there’s already a way to do something, it doesn’t mean it’s the right way to do it.
Some of the greatest innovations have in fact been a reinvention of the wheel, because what already existed at the time wasn’t good enough. Imagine someone telling James Watt he shouldn’t waste his time reinventing the wheel. Improving what already exists means we have stable foundations and better tools to work with in the future. The wheel itself has been reinvented multiple times, hence we don’t use Bronze Age wheels anymore.
A good example in the software world of why sometimes reinventing the wheel is a good idea is UNIX vs Windows. UNIX was written from scratch to replace Multics which had serious flaws, so they ended up with a new and clean system, built right from the bottom-up. They reinvented the wheel and made huge innovations in the process. Windows on the other hand, is built on top of MS-DOS which even at the time was a mess, so what Microsoft is left with is an OS which up to this day is overly complicated, because of fundamental design flaws that cannot be fixed unless they do away with the whole thing and start from scratch. Instead, they are coming up with half-assed solutions and add complexity to the system with each update.
Then there’s quality and efficiency. Writing your own tools means they can be tailored to perform a specific task perfectly — something a big generalized framework or piece of software can’t do in many cases. We tend to ignore the improvements better software can bring in the long term and instead spend time fighting with not-so-great tools and also rely on the power of modern hardware to cope for our mediocre solutions (see modern web tools or the web in general).
So, am I proposing that we’d be better off writing machine code and building our own programs for everything? Absolutely not. What I AM saying though, is that instead of being allergic to reinventing the wheel, we can start to see the merits in it, without overdoing it. This approach is benefecial to our personal improvement as engineers, which means an improvement in software as a whole. Just as you learn any other skill by mastering and understanding the basics, programming has to be understood from the bottom-up, not the opposite way. There’s no point in knowing all kinds of fancy frameworks if all you see are black boxes, or cannot even implement a linked list if asked to. After all, it’s a fact that software is getting worse.
And to save myself from sounding ignorant, there are cases where reinventing the wheel is a problem, namely:
- Companies rolling their own proprietary solutions for everything, and ending up creating protocols and programs, which are arguably worse, expensive, harder to maintain, and incompatible with existing software.
- People who like to reinvent the wheel for the sake of just having “their own” version of something, even when there actually is good software out there that covers their needs just as well.
Knowing how things really work will enable you to trace bugs easier, write/design more performant software, and overall know what the hell you’re doing. And that can only be achieved by, sometimes, reinventing the wheel. Nothing can teach you what getting your hands dirty will.