Hacker News new | ask | show | jobs
by sunrunner 461 days ago
Like every single software development principle, this phrase really needs to be explained with more context and considered with more subtlety than the usual "It's best practice" advice, for a number of reasons (some of which are stated in the article) of which I think the following two are the most important:

Firstly, if you want to actually understand how the 'wheel' is invented then yes, you should re-invent it. The process of re-invention involves discovering what actually goes into some of the tools you use. Even if you never use your re-invented wheel in public (often advisable), the process of learning is invaluable in understanding the tools you do use.

Secondly, however, what wheel are we even talking about? The wheel is a timeless design, seemingly perfectly suited its task. The software libraries and tools that are usually picked as targets for 'not re-invention' are not wheels. They're higher level abstractions that pre-suppose certain ways of working. There's no timeless design here, just a bunch of arbitrary desicions about how something should work at a higher level with some amount of the decision making you'd have to do without it already done. Is this a bad thing? Of course not. But understanding that all of the 'wheels' are just this and are not magical black boxes that can't be understoor or shouldn't be looked at is important.

There are good times to not immediately go and re-implement *and publish* existing tools (emphasis on the publish, you should do things for learning), but understaning why you're choosing to do or NOT do a 'reinvention' is crucial.

5 comments

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.
There is so much work put into bicycle wheels, and you can carefully select a wheel depending on if you are building a time trial bike, a regular road bike, a commuter bike, mountain bike…

If we could create physical things as easily as software, we’d absolutely see bicycle hobbyists and certainly little shops designing their own wheels.

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 is well-put. I think it speaks to "its the journey, not the destination", not learning to ski by only reading books, and Chesterson's Fence[0], off the top of my head.

[0] https://fs.blog/chestertons-fence/

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

Re-invented or re-implemented? The design was always the same just the materials have changed (and maybe there's something about motor racing and new wheels being available every year...)
Software all uses electricity, doesn't it?
> 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.

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