Live data from Hacker News

Wheel Reinventor’s Principles (2024)

tobloef.com

1–10 of 101 posts

Re: Wheel Reinventor’s Principles (2024)

#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 bugs in the 90%.

Re: Wheel Reinventor’s Principles (2024)

#8
post #6

Should mention NIH syndrome. https://en.wikipedia.org/wiki/Not_invented_here

Yes, it has to be balanced appropriately. I didn't emphasize this a lot in the blog post, but this is really important in a work setting, compared to when working on personal projects. I still think wheel-reinvention has its place in professional teams, but the related challenges should be taken more serious in that case.

Re: Wheel Reinventor’s Principles (2024)

#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.

Re: Wheel Reinventor’s Principles (2024)

#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.
Post reply on HN