Do reinvent the wheel.

Throughout the years, I have been told numerous times not to reinvent the wheel. In principle, this is sound advice. But a piece of advice repeated thousands of times becomes a mental rule – harmful and prejudicial.

We've taken it too far

It has led us to the point where developers avoid writing custom code at all costs and instead spend months researching libraries. Yes, you read that right, months. True story 🤯 Funnily enough, the library that they picked, nurtured, and made half of the app reliant on got abandoned not more than a few months later.

In the meantime, their main competitor developed an in-house solution, released it to production, and started marketing around it. In theory, picking a library ought to give you a head start. In reality, though, that's often not the case.

I believe the mindless chanting of "do not reinvent the wheel" turned many workplaces and projects into toxic environments. Developers are afraid of putting themselves on the spot, being judged, and possibly failing. They'd rather shift the center of gravity and all attention toward the libraries and their authors.

The time-saving fallacy

„But isn't that good?” you may ask. Great question; I'm glad you asked. The answer is: it depends. Using libraries is supposed to save you a ton of time. Unfortunately, once the library is picked, the developers usually need to spend countless hours trying to bend it to their needs. The library does 90% of the job, which is great, but the remaining 10% requires the developers to become MacGyvers and implement a quick and dirty duct tape solution.

Not to mention the time and money costs of relying on external dependencies: bugs that go unfixed for years, projects that are abandoned, and breaking changes in releases. Maintaining a codebase with more than a few external dependencies seems daunting.

The external dependencies

I am not immune. Just recently, we were faced with the task of implementing a search engine for yournextstore.com. I tried one library, which kind of worked. Then I tried another, which was significantly faster but lacked one of the features that we needed. Oh, and it had 1231 features we didn't need.

It took us a month of meandering to ask ourselves: How hard would it be to implement search on our own? I wrote down the requirements: full-text in-memory search with prefix search, suffix search, and scoring, but no fuzzing. I started coding. It was done in less than a day. It worked 10x to 20x faster than the library we picked previously.

The "don't get me wrong" paragraph

Don't get me wrong. I'm not trying to convince you to abandon all dependencies and rewrite everything internally. It's all about the balance.

If you've decided to build your own framework, I suggest you reconsider. It's unlikely you'll match the quality and velocity of other popular solutions, and you'll make the learning curve cliff-like for new hires.

But a tooltip? A datagrid? A carousel? Even a simple search engine? Those are the examples where going completely custom really shines. Not only are those problems actually easy to solve, thanks to the modern Open Web. But by zeroing in on your specific use cases, you'll be able to trim tens or hundreds of kilobytes off of the bundle compared to the libraries.

Not every problem needs a pre-made solution. Sometimes, rolling your own can save you headaches down the line. Reinventing the wheel isn’t always bad. In fact, it might just be the best decision you make.

Please, by all means, sometimes do reinvent the wheel.