Roll your own
In defense of reinventing the wheel
In software development, “rolling your own” means writing your own version of a module or tool when there are similar ones available elsewhere. The expression is usually used negatively, as in, “Why would you roll your own when there are perfectly good solutions that already exist?” Another synonym is “reinventing the wheel,” as in, “Don’t reinvent the wheel.”
I’ve been thinking about this because I recently turned 30 and noticed a change. As I’ve gotten older I’ve started to spend too much time analyzing existing solutions and approaches. When I was in high school or college I was more likely to charge ahead with my own ad-hoc version. From what I’ve seen and read, this is a common thing that happens to people, and is usually viewed as a sign of maturity.
There is a balance, of course. But this essay is a reaction against the force of aging and will argue in favor of the young person’s roll-your-own style.
First I’ve give an argument in terms of good system design.
The good-system-design reason to roll your own is that any existing thing comes with its own interface and abstractions. So if you want to use it, you have to learn the particular quirks, and then write adapters for your own system. And then you’ll have to write your own handlers anyway for the edge cases that the existing thing doesn’t do. So you end up taking more time to use the existing thing, and you end up with more complexity. You have more complexity because there are more interfaces, an additional dependency, and more special cases. Interfaces, dependencies, and special cases are all forms of complexity and are therefore bad.
Here’s how it plays out: a voice says, “Why are you using the addition operator when there’s already an existing package for adding numbers? You probably haven’t considered all the special cases. Package XYZ already handles those for you, so don’t reinvent the wheel.” Then if you listen, you have to find all examples of c = a + b in your code and replace them with c = XYZ.addNumbers(a, b). Actually, that’s an oversimplification because package XYZ probably also provides its own Number class, so you can’t pass in your a and b. It would be more like:
import XYZ
a2 = XYZ.Number.from_float(a);
b2 = XYZ.Number.from_float(b);
c2 = XYZ.addNumbers(a2, b2);
c = c2.to_float();
Oh, and you have to rebuild your environment to get XYZ installed because it conflicted with the latest version of package ABC. This of course, is the extreme case, which has all the costs of using the thing that already exists and none of the benefits. When XYZ is hiding lots of complexity for you, well suited to your system, and has a clean interface, then you’ll be better off using the thing instead of rolling your own.
That is, rolling your own is better except when it isn’t.
That’s the sort of reasoning about when the system itself will be better off with custom parts or stock parts. But systems don’t exist on their own; they’re written by people, and there are more personal and practical factors.
First, you learn a lot more by doing things yourself. Quoting my Twitter:
That’s a good reason for young people to write their own versions of things, because they have more to learn. It’s also better for young people to roll their own because they’re more likely to be working on their own projects. When you work on a team it would be considered bad taste to substitute your own thing if it were pretty much the same as a standard version. But the learning benefit is real.
The last reason I’ll give is that it takes time to analyze existing things that might be relevant to your system. Often there are lots of related things in existence, and all of them are OK, but not perfect. So you may as well let your own version be the tie-breaker.
ChatGPT has been good and bad in this respect. It makes it easier to find useful modules, which is good. But it can cause decision paralysis. You quickly discover there are lots of options, and ChatGPT will gladly make tables for you with all sorts of comparisons between the different options. So it makes researching existing things easier, but that can end up causing you to do too much research. Whereas before I might have Googled something, not seen much, and then happily went on my way, now I feel a burden to analyze all possible paths.
The advice not to reinvent the wheel is dangerous because it sounds so reasonable and responsible. That’s another problem with using ChatGPT to research existing options. It’s calibrated to sound reasonable and responsible, so it’s likely to be another voice telling you not the reinvent the wheel.
I’ll end by saying that when you do roll your own, you should still do good design. It should be well documented, cleanly modularized, etc., so that someone else (or you in a few months) will be able to understand how it works. In other words, if you’ve done a good job rolling your own, you’ll tempt the next person not to.


