|
|
|
|
|
|
by crtlaltdel
2321 days ago
|
|
|
i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support. before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..." |
|
|
I mean, how hard could building our own pick & place be, right? Once you strip out all the bloat the vendors add to make a sale, it is nothing you couldn't do with a couple servos and a $5 Arduino, right?
I think the "build everything ourselves" attitude comes from a not at all understanding opportunity costs and comparative advantage. Plus in the software industry, tons of developers I've encountered are super paranoid about "vendor lockin" without realizing that once they roll their own library/framework/pick-and-place-machine they have effectively locked their employer into a vendor as well. Only instead of a third party vendor with all the benefits that may come with it, they've "purchased" a product from a really shitty vendor--themselves!
It is never a choice between:
"Platform or no platform"
"Framework or no framework"
"Vendor lock-in or no vendor lock-in"
You will always be on a platform. You will always be using a framework and you'll always be locked into a vendor. The trick is to make sure you don't lock yourself into a shitty vendor who makes a shitty platform or framework.