Wheel Reinventor’s Principles (2024)

The usual allegoric rebuttal is to show how many types of wheel there are, and how wheels have improved over time. The wheel as a basic concept is to mount a rotating circular shaped thing on a platform for moving. The first wheels were made of wood, at some point spokes were introduced, then other materials. Many more innovations (many of them mutually exclusive) are required to realize a formula 1 car, or a ralley car, or a bus, or a plane.

Sometimes when reinventing the wheel, you realize that pot-holes suck. Learn to appreciate the wheel and reinvent the road. Learn to appreciate the road and reinvent the rocket. I guess I'm walking home.

> this phrase really needs to be explained with more context

No, absolutely not. This is a first person problem.

The primary reason to reinvent wheels is to provide the most immediate and/or portable solution to a problem. By immediate I mean only from the perspective of the product.

That is a first person problem because many people cannot, such as neurological impairment, imagine any operating condition beyond the efforts of their own individual labor. That is where the cliche of not reinventing wheels is most used as an empty defensive argument.

We re-invented the wheel quite some times.

Stone, then wood, then wood with spokes, then wood with spokes and iron trim, then we eventually added rubber, rubber tubing, then all metal spoke with rubber. For Mars rovers they made new types of air-less wheels.

The saying ‘do not reinvent the wheel’ is just silly

It's probably more interesting to reinvent things on the lower abstraction layers, otherwise we're just reinventing design decisions.

Hard agree. A library should not inflict complex use cases' complexity on simple use cases, but sometimes they do, either because they're poorly designed or because they're overkill for your use case. But often I see pain and complexity excused with "this is the library that everybody else uses."

Sometimes a simple bespoke solution minimizes costs compared to the complexity of using a massive hairball with a ton of power that you don't need.

One big caveat to this: there's a tendency to underestimate the cost and complexity of a solution that you, personally, developed. If new developers coming onto the project disagree, they're probably right.

I'm not sure, perhaps this is an issue with how our craft is taught, but I think we're missing something when we talk about the (economic) tradeoffs when making these decisions.

Keeping components simple, decoupled and with minimal dependencies allows for a high degree of optionality. When you pair this with a simple system that is easy to reason about - you're doing huge favours to your future self.

On the other hand, hanging off a bunch of unused features, especially ones that have interacting configuration - that's more like adding lead weights to your future self. It weighs you down and adds friction. And we tend to do a terrible job of predicting our future needs.

Kent Beck does a great job discussing the costs of these tradeoffs in his recent book "Tidy First". It builds upon the YAGNI principle, but adds a level of cost analysis that should allow you to sell these ideas to the managerial level.

The concept of Don't Repeat Yourself and the concept of You Ain't Gonna Need It are the yin and yang of software development.

I don’t think there’s an accepted set of concrete criteria for making software that can absorb major design changes later without a great deal of effort and stress. How you write code that can accept an abstraction layer at the last responsible moment.

Some people have an intuition for it, but it’s sort of an ineffable quality, buried in Best Practices in a way that is not particularly actionable.

So people having been scarred by past attempts to refactor code reach for the abstraction in fear, just in case, because they don’t know what else to do and it’s not written down anywhere, but abstractions are.

Another good way I've seen it put is, the difference between underengineering and overengineering is that you can fix underengineering.

Reinventing certain wheels is arguably the only way to be sure you understand them. For example Monte Carlo sampling implementations.

The logical conclusion of this mindset is mathematics, where people literally prove all of algebra and calculus to themselves as they learn it. There are good pedagogical reasons for doing this.

Good points, all of them.

Especially the last one is just a painful reality of the process. I think it's somewhat similar to the scientific method in that regard. Often your hypothesis is just false, but that does not make the attempt less valid.

I this this ought to be an iterative process, such as study principles so that you don't start from absolute scratch, then make a wheel that sucks, study some more and do more resarch yourself, rince and repeat until satisfied.

There is so much nuance that doesn't get captured in all the study you can do about how a certain thing is made.

But when you need other people to work with your wheel it's much harder to find those capable enough/that want to deal with that. Also when shit hits the fan and the wheel reinventor left the company you're gonna wish you had a standard wheel.

(I am a wheel reinventor btw)

> It's funny how often engineers say "it depends"

Then just wait until you speak with lawyers.

“Tramway Drifting and Dungeon Exploration Simulator”

I thought I knew what those words meant but as I read the README I realize I don’t.

I am clearly not the intended audience for whatever that is.

This. I'm trying to set up a personal developer blog and I have a very specific set of requirements. Tried several static blogging frameworks. Apart from the software bloat, I found myself spending a gratituous amount of time trying to customize pieces to my needs. Finally got sick of it, landed up writing a python script and after a few days and < 200 lines of code - I have a working prototype that fits my current needs. I will be doing more of the wheel re-inventing for other projects I have in mind. I strongly agree with your observation that adapting generic frameworks to specific needs probably have longer learning curves than just building a new wheel.

The specificity reason is interesting as it relates to what feels like an assumption in software that all software components are neatly shaped boxes that a) perfectly encapsulate an area of functionality and b) can be placed into neatly shaped holes of 'required functionality', neither of which ever seem to be true.

The boxes are always weirdly shaped with odd edges, and the holes they have to fill are always oddly shaped. The code written to join the two is at minimum glue that seals the two edges, but also usually involves converting one shape to another.