Why you should consider reinventing wheels if you are an innovator
The world would be very different if we followed that advice strictly
Imagine a world without Pepsi, Apple or Stripe. That would be the world we live in if innovators adhered strictly to the adage of “Don’t reinvent the wheel”. I’d argue innovation requires we break that rule.
A case for using the wheels we have
So why do folks love to reuse the wheels that exist? Let’s take a look at some very rational viewpoints:
Many solutions are free and reliable which translates into “safe” and predictable. OSS libraries being the most obvious choices.
There exists a common knowledge (e.g. folks know and understand Entity Framework for instance). Things tend to move quicker when we can speak a common language.
The problem is easy to understand, but hard to solve (e.g. paid PDF libraries, auth providers, cloud hosting, etc). “We’re a financial company, not an authentication provider”. Folks simply don’t have the ability or capacity to do things that aren’t core to their business.
Everything has consequences
The list above is a very good reason to use what already exists. But let’s look at some of the darker side of “not reinventing the wheel”:
The solutions are typically not a great fit. If you are paying for the solution, you’re likely paying for features you don’t use.
You’re likely locking yourself into a vendor. Orgs typically won’t be changing cloud providers, auth providers or frameworks very often. Sales people use this to their advantage. This one is hard to avoid but in the long-term can be an albatross around our necks.
Common knowledge is great until it turns into groupthink. This happens when an ORM is used (let’s say NHibernate) and Entity Framework is not chosen. This ends up shaping who you hire and who you don’t because job listings typically advertise “the stack”. A lot of tech debt grows out of this one because of the audacity it takes for someone to change how things are currently done.
Companies erode their in-house talent and leads to attrition. A company that can’t understand the base problem/solution — will end up outsourcing to a company who does. Their in-house talent will be nothing more than plumbers (generalists) who will not own anything interesting which hurts job satisfaction. When a novel problem plagues the company, the generalists can do nothing more than google a hasty solution.
The second mouse gets the cheese
Here in America we often utter “the early bird gets the worm”. In most cases that is true, but often times the bird becomes satisfied and loses the drive that the original hunger provided.
In the context of business, the second mouse typically gets the rewards because of the unfortunate nature of being in the vanguard when approaching the mousetrap. Apple has a long history of innovation, however in the early days they “borrowed” a lot of technology from competitors (Xerox, Microsoft, etc). Having the perspective of seeing the problem being solved from afar allows innovators to have insight that the original authors no longer see. Apple obsessively reissues new generations of iPhones and iPads as they have a healthy internal process to build a better mousetrap. If Apple didn’t reinvent wheels, we’d not have the smartphone/tablet revolution we are experiencing today.
The perceived perils of building a better mousetrap
Innovation can be bloody. It requires an investment and a large amount of faith. The reason companies prefer the safety of existing solutions can be found below:
“What if the dev who wrote it quits?” - A common fear by management. However I’d argue this is only a risk because the manager is siloing work instead of having offsetting the risk through coownership of a codebase.
“What if it doesn’t work?” - I’d reply with “What if it does?”. Choose the right people to build the solution and this won’t be a problem.
“What if it’s a big ball of mud when done?” - This is a function of also choosing the right people. No perfect solutions exist, but you’ll definitely know a bad one when it comes along. Even Apple has crappy code in their repos.
“What if it takes too long?” - If this is a concern, then you have a scoping/planning problem and not a “this is taking too long” problem. If your org cannot plan properly, then you likely will fail.
“What if it’s not scaling after some time?” - This is a good problem to have. It means you scoped it to what you needed at the time and it’s ripe for the next iteration. There is no such thing as “done” in my opinion — just the next evolution.
Good engineers like to solve problems. By tasking engineers with a problem to solve, they will feel appreciated. Like any project, proper expectations and scope need to be set. There’s no need to match a competing product feature-for-feature. You only need to solve the actual concrete problem you have in front of you. Don’t make the mistake of adding features “just in case”.
The benefits of owning your own wheels
One of the hardest things to do with software you don’t own is convincing the owner to adjust/alter their code. Existing wheels are often very generic so that they can solve the most problems. When you own your own solutions, you might be able to enjoy the following benefits:
Solve your org’s unique problems.
Grow your in-house skills.
Grow your leaders by empowering, trusting and relying on them.
Avoid recurring licensing/subscription fees.
In rare cases, your in-house solution solves other orgs problems. This has happened a fair number of times and has given a huge boost to the original brands:
React (Facebook/Meta)
Axios JavaScript Library
StackExchange.Redis
Dapper
Bootstrap (Twitter)
How to decide to use existing wheels or reinvent them?
Problems are common, solutions are opinionated. Every design/engineering decision needs to go through a “Make or Buy” process. At a minimum, each decision should consider the following questions to guide your decision:
Opportunity cost - Do you need this now? Or can we wait? If you have the ability, do you have the time?
Ability - Does your org have the ability to build, operate and maintain the solution?
Existing solutions - Do any existing solutions cover the core problem? Is it affordable? Is it cheaper than having in-house talent build/maintain?
Shareability - Is the data involved sharable to a third-party? Can you self-host? Does it require losing custody of private information?
Not so fast
Innovation requires guts. The next time someone says “don’t reinvent the wheel”, I want you to recall this article. It’s not a universal truth in my humble opinion — rather it’s a nuanced discussion that requires a case-by-case make/buy decision.
If your company has a tech stack (who doesn’t?), think of how hard it would be to change one or more of the items without encountering some sort of resistance. If you seek a completely safe, risk-free, stable environment — the tech industry may not be for you. Dare to take your company to the next evolution.