And for good reasons. I think there is an almost ignorant annoyance with devs who reinvent, but a lot of times they’re reinventing a punctured wheel or the wheel is for a bulldozer and they need one for a minivan.
I had this exact experience: “why should I reinvent the wheel?” Oh this solution doesn’t let you apply partial payments or apply one payment to multiple invoices. This one doesn’t create account statements. This one can’t fax invoices. This one only supports Stripe (and has its own undocumented billing API because who would use anything other than Stripe?). This one has a weird XML definition system for subscription pricing which makes it difficult if not impossible to handle negotiated rates on a per-account basis. Not to mention having to teach billing people how to write the weird XML. This one won’t prorate invoices. This one is a cloud service that costs $100+ a month and is liable to be unavailable when I really need it! They all have weird features that I will never use.
Ok, we’ll go with this imperfect one and make some changes. But where’s the entry point? How does weird framework in weird language even work? What are the conventions? How is the original developer differing from those conventions?
And then you come to the realization that the wheel gets reinvented because the existing wheels were made with specific business logic in mind. While this can often be generalized for a particular industry or set of use cases, it often does not and can not cover all use cases. The wheel is reinvented.
(Not so fast with the XKCD comic about new standards. We’re not imposing standards on others, we just need our software to work for us.)
Sometimes the wheel doesn’t need to be reinvented. Some help desk software I wanted to use needed some slight tweaks. The entry points were obvious and the development environment was easy to setup. I made the tweaks and was good to go.
It sometimes feels to me, like a huge percentage of developers reinvent the wheel