Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wheel Reinventor’s Principles (2024)

tobloef.com

Post reply on HN
Print view View original

41–50 of 101 posts

Re: Wheel Reinventor’s Principles (2024)

#41

Post by sunrunner »

the__alchemist wrote: post #9

I am a wheel re-inventor. Nice article. The _Specificity_ reason listed is usually the driving factor for me, with the others being downstream effects. In short, the wheels are often built for a different chassis than the one I'm using. Adapting these may be more difficult than making 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.

Re: Wheel Reinventor’s Principles (2024)

#42

Post by convolvatron »

turnsout wrote: post #37

There's a big difference between "reinventing the wheel" and simply making your own wheel. People often conflate the two. e.g. making your own static site generator is not reinventing the wheel. It's making your own wheel, which is a perfectly cromulent use of time.

there is an implicit assumption that we've all settled on what transportation looks like. its a car with 4 wheels, and windows, and a chassis and a glovebox. there are already a whole spectrum of gloveboxes we can but, open source, SaaS, etc.

why would you make a new glovebox. its got a latch, and a hinge.

maybe I dont even want to build a car.

Re: Wheel Reinventor’s Principles (2024)

#43

Post by 0xbadcafebee »

More thoughts about reinventing the wheel:

- Did YOU invent the last wheel, or any before it? If not, then you will make the same mistakes the last inventor made. Until you make a bunch of wheels, you'll probably suck at it.

- You learn more by studying old wheels than trying to bang one out yourself. Study the principles behind the designs rather than shooting from the hip. This is why we study medicine, science and engineering, and don't try to invent new medicines, sciences, and engineering disciplines from ignorance.

- Novel-ness is only good when it fixes more problems than it introduces. Novel-ness introduces not only "bugs" from a new, untested design, but also the problems of changing people's expectations, requiring new training, and possibly requiring all the other parts to change to fit the new wheel (which is often more work than just dealing with the old shitty wheel!). New things are not inherently good. Incremental change is almost always better, even if it's harder because you have to struggle with all the existing limitations. Your job isn't to do something easy, it's to make a product better.

- Only after you make your new wheel will you find out if it's good or not. Don't go into it assuming what you have is better just because you like the idea of it better. In fact, the more you like the idea, the more you should question it; ego is a dirty liar. Kill your darlings and be prepared to accept others' judgement of the thing, and the reality of it moving on the road.

Re: Wheel Reinventor’s Principles (2024)

#44

Post by JackFr »

jofer wrote: post #35
dkarl wrote: post #17

Earlier quoted context omitted.

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 p…

The big caveat is a big one. Choose your battles wisely! There are plenty of things that look simpler than an established library at first glance (I/O of specialized formats comes to mind quickly). However, a lot of the complexity of that established library can wind up being edge cases that you actually _do_ care about, you just don't realize it yet. It's easy to wind up blind to maintenance burden of "just a quick…

> I/O of specialized formats comes to mind quickly

The classic "I'll write my own csv parser - how hard can it be?"

Re: Wheel Reinventor’s Principles (2024)

#45

Post by didgetmaster »

motorest wrote: post #24
didgetmaster wrote: post #20

Reinventing the wheel often means breaking things. Innovation often requires getting rid of backwards compatibility. The status quo is promoted by those who have invested in it, so disrupting it can be met with fierce resistance. When I tell people that file systems are antiquated and need to be replaced with something much better; I often get strong push back. This is a wheel that I have been reinventing for some ti…

> Reinventing the wheel often means breaking things. Innovation often requires getting rid of backwards compatibility. The status quo is promoted by those who have invested in it, so disrupting it can be met with fierce resistance. This is a terribly simplistic take. To start off, it ignores the fact that major rewrites are known for failing. https://www.joelonsoftware.com/2000/04/06/things-you-should-... It also doe…

Of course many new wheel inventions fail, and mine could very well be among them. You never know if you don't try.

The alternative, of course is to simply accept that all wheels already invented work just fine and don't need to be fixed.

Which approach is the most 'short-sighted'?

Re: Wheel Reinventor’s Principles (2024)

#46

Post by geysersam »

dkarl wrote: post #17
JackC wrote: post #7

I'll add "reduce code size and complexity" to the list of benefits. A python library to calculate a simhash, or track changes on a django model, or auto generate test fixtures, will often be 90% configuration cruft for other usecases, and 10% the code your app actually cares about. Reading the library and extracting and finetuning the core logic makes you responsible for the bugs in the 10%, but no longer affected by…

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 p…

At my current workplace the word "bespoke" is used to mean anything that is "business logic" and everyone are very much discouraged from working on such things. On the other hand we've got a fantastic set of home made tooling and libraries, all impressive software engineering, almost as good as the of the shelf alternatives.

Re: Wheel Reinventor’s Principles (2024)

#47

Post by TobLoef »

turnsout wrote: post #37

There's a big difference between "reinventing the wheel" and simply making your own wheel. People often conflate the two. e.g. making your own static site generator is not reinventing the wheel. It's making your own wheel, which is a perfectly cromulent use of time.

To me this is one of the differences between making a wheel for learning or a wheel for innovation, as I mention in the blog. The latter can truly be reinvention, while the former is indeed often more like simply making your own wheel.

Re: Wheel Reinventor’s Principles (2024)

#48

Post by rambambram »

austin-cheney wrote: post #11
roland35 wrote: post #10

It's funny how often engineers say "it depends"! Even a basic axom like don't reinvent the wheel doesn't always apply. After all, we have entire industries dedicated to doing exactly that! Goodyear spends a lot of time investing in new wheel technology every year.

> It's funny how often engineers say "it depends" Then just wait until you speak with lawyers.

I laughed out loud and can't agree more. If I have to boil down law school to one sentence, it's this one... it depends on the particular circumstances.

Re: Wheel Reinventor’s Principles (2024)

#49

Post by didgetmaster »

glitchc wrote: post #29
didgetmaster wrote: post #20

Reinventing the wheel often means breaking things. Innovation often requires getting rid of backwards compatibility. The status quo is promoted by those who have invested in it, so disrupting it can be met with fierce resistance. When I tell people that file systems are antiquated and need to be replaced with something much better; I often get strong push back. This is a wheel that I have been reinventing for some ti…

We need content addressable FSes with bloom filters for fast lookups.

That might be what we need, or not. But we do need to look at different approaches and figure out something better.

Re: Wheel Reinventor’s Principles (2024)

#50

Post by LPisGood »

JackFr wrote: post #44
jofer wrote: post #35

Earlier quoted context omitted.

The big caveat is a big one. Choose your battles wisely! There are plenty of things that look simpler than an established library at first glance (I/O of specialized formats comes to mind quickly). However, a lot of the complexity of that established library can wind up being edge cases that you actually _do_ care about, you just don't realize it yet. It's easy to wind up blind to maintenance burden of "just a quick…

> I/O of specialized formats comes to mind quickly The classic "I'll write my own csv parser - how hard can it be?"

What are some footguns? It does seem easy
Post reply on HN