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:<p>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.<p>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.<p>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.
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 bugs in the 90%.
> [...] Be wary of abstractions made for fabricated use cases.<p>Very well put and I would argue this applies to general software development. This is one of the biggest difference between my freshly-out-of-college self and me right now and something I try to teach engineer I'm trying to grow into "seniors".<p>Too many time have I seen a lot of wasted efforts on trying to build hyper flexible components ("this can do anything!") to support potential future use cases, which often never come to be. This typically results in components that don't do that much and/or are hard to use.<p>Design your components as simply as you need them, but no simpler. This typically gives more flexibility to grow rather than accounting for currently-not-needed use cases.
In scientific software development "don't want to reinvent the wheel" is an oft-repeated mantra that I like to push back on when I hear it. To be fair it's often used in the context of "we'd rather/like to collaborate", rather than an appeal to use "that exact thing".<p>Re-inventing things independently in parallel (parallel evolution analogies) is perhaps a strong indication that something interesting is going on. How do we know we got it "right" if we don't converge independently? If we invent a square wheel, and stopped because "wheel", we'd be in a horrible place. Science is a process, the process of reinventing is a great way to realize new things, and to train, at a low level, scientists. I suspect the process of re-inventing is also important in building out our (long term) ability to depend on our "gut feelings", thus providing the ability to nudge us to experiment along one path or another.<p>[Edit ... all things the article mentions.]
More thoughts about reinventing the wheel:<p>- 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.<p>- 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.<p>- 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 <i>not</i> inherently good. Incremental change is almost always better, even if it's <i>harder</i> 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.<p>- 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.
I find that for me to deeply understand something, I have to reinvent it. There's SO many nuance not captured in textbooks or papers. I reminds me of the feeling of attending lectures by great teachers. Everything makes so much sense until you start the homework assignment.
Creating a lighter, faster wheel that only works with sort of cart your company builds might invite accusations of “reinventing the wheel” but often it’s just “doing engineering”
Most importantly, roll your own crypto!*<p>*<a href="https://www.schneier.com/blog/archives/2015/05/amateurs_produc.html" rel="nofollow">https://www.schneier.com/blog/archives/2015/05/amateurs_prod...</a>
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.
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.
"I am not reinventing the wheel, I am disrupting the wheel industry"
— TramSDK creator <a href="https://github.com/racenis/tram-sdk" rel="nofollow">https://github.com/racenis/tram-sdk</a>
Great post!<p>If you're a PL/compiler/GC hacker, then here are wheels you <i>should</i> reinvent in order to even just have a basic idea of WTF is going on in the Big Serious Production Wheels that you might end up being gainfully employed to maintain:<p>- Invent your own language, and write at least an interpreter for it, to get a feel for what makes a language work at all, or not.<p>- Invent your own compiler IR. Don't worry if you make a bunch of mistakes. Don't worry about whether you follow my advice for how to do it, or anyone else's advice. Make it your own and learn from your mistakes.<p>- Invent your own way of doing the major compiler optimizations. Of course there are established ways of doing SSA conversion, CSE, constant prop, regalloc, instruction selection, etc. But you won't know <i>why</i> they are that way unless you try to make your own, and then either succeed because you are smarter than everyone else (it's possible that you are), or succeed because you literally reinvented the wheel (then you understand the compiler's wheels better than your friends because you got there from first principles), or you'll fail (most likely outcome) but then you'll understand why the real wheels work the way that they do better than others.<p>- Reinvent memory management. Write your own GC or whatever.<p>That's how I learned the craft. Can't think of a better way to learn.
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.<p>When I tell people that file systems are antiquated and need to be replaced with something much better; I often get strong push back.<p>This is a wheel that I have been reinventing for some time. It's not something that can be fixed with minor tweaks.
I decided to reinvent SVG Filters because Safari won't let them be used with HTML canvas elements[1] ... well, at least that's the official reason.<p>Unofficially I just wanted a decent filter engine[2] that worked well with my canvas library, and there were things like SVG "filter chaining" which I really liked the idea of - but could they be done in a simpler way[3]? Also: proving to nobody that canvas filters can be done (fairly) efficiently without the need for WebGL shaders (because: why not?). And then I discovered I really like coding up filter functions and went a bit mad with them[4][5] and now the hole is so deep the only option left for me is to keep digging ...<p>[1] - Though I think that's changing this year? May already have changed - but I'm not gonna un-reinvent my filters even if the Safari folks have shipped the fix!<p>[2] - <a href="https://github.com/KaliedaRik/Scrawl-canvas/blob/v8/source/helper/filter-engine.js" rel="nofollow">https://github.com/KaliedaRik/Scrawl-canvas/blob/v8/source/h...</a><p>[3] - Why do the SVG filter primitives need to be so complicated to work with?<p>[4] - <a href="https://scrawl-v8.rikweb.org.uk/demo/canvas-007.html" rel="nofollow">https://scrawl-v8.rikweb.org.uk/demo/canvas-007.html</a><p>[5] - <a href="https://scrawl-v8.rikweb.org.uk/demo/filters-103.html" rel="nofollow">https://scrawl-v8.rikweb.org.uk/demo/filters-103.html</a>
> Minimize third-party dependencies. Master the platform’s built-ins and accumulate your own toolbox over time.<p>I would like to work with this person.
There's a big difference between "reinventing the wheel" and simply <i>making your own wheel.</i> People often conflate the two.<p>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.
The single biggest advantage of a self invented wheel is that you know how to use it. Most lines of code you write, because you know what they mean. Getting to know the pros and cons of somebody else's wheel is often quite an investment.
I follow advice I heard decades ago (by I think John Carmack): Implement it yourself and then throw it away.<p>This is a great way to learn <i>why</i> libraries and tools like compilers are the way they are.<p>I practiced this in the late 90s by making my own 3D maths library and my own “standard” library.<p>I ended up using the built-in 3D maths in DirectX and the C++ STL in the commercial game engine code I worked on later. But having practiced on my own libraries helped me understand the standard ones a lot better.
I think these folks, who reproduced the aircraft of the Wright Brothers using similar materials, methods, and tools, are a peak example of the value of reinventing as a path to deeper understanding.<p><a href="https://www.wrightexperience.com/" rel="nofollow">https://www.wrightexperience.com/</a>
I'm definitely a wheel re-inventor (in the educational and entrepreneur sense), and I've come across the same learning points myself. Recently, I just started blogging about my little wheels, and I think its been one of the most satisfying aspects of working on a project!
A lot of time I find myself reinventing the wheel is because of some framework that has decided that inverted catenary flooring is the future and their provided wheels are excellent for going in the standard use case direction.
The color contrast of the site, especially the background color and the font thickness (on android phone at least) is not good. Many visually impaired people would have very difficult time reading the content.
Missing point: only reinvent the wheel when you control all the wheels<p>For large, complex systems with multiple developers this approach rarely works.