3 ms·

Would you rather do some library gluing, or reinvent a thousand wheels with every project? The latter is neat the first few times. Whatever your preference, you

Would you rather do some library gluing, or reinvent a thousand wheels with every project? The latter is neat the first few times. Whatever your preference, your value as an engineer is much higher if you can glue. Imagine if a carpentry workshop gives a carpenter a fully-fledged set of industrial power tools, but the carpenter insists she can recreate all the other tools with just her whittling knife because it's in the 'true spirit of carpentry'.

deathanatos 4y ago
I'd rather re-invent some wheels. The problem with VendorOps as I see it is that quite often the vendored "solutions" aren't solutions: they do not meet the requirements! Yet … they sort of get like 20% of the way there, so they get adopted nonetheless, and the devs toil away on trying to get glue code to push it the remaining 80% of the way. But if we had a system that we owned, then it could be adjusted to fit the requirements, elegantly. But we don't, so we can't. The other problem is the "Ops" part: vendor owned systems are opaque AF, and when something goes wrong, impossible to debug. Then you become a support ticket monkey, praying you can convince the powers that be on the other end that a. it is truly their stuff that's broken, not yours and b. we pay for it, so yes, you should support it. When a. or b. fails, then you end up writing yet more glue code to try to work around the bugs and outages that your vendor just doesn't give a shit about.
- Aeolun 4y ago
  We got random failures on our API gateway to lambda connections, and the answer we got back from the support agent was something like “automatically retrying on failure is industry best practice”. I just wanted to shout at them to fix their damn system, but of course we ended up implementing retries instead…
  - agent281 4y ago
    For a while AWS Glue had an issue where the running job counter would permanently increment. This was a problem if you only wanted one copy of a job running. The advice support gave us was to increase the allowed count by one. I saw references to this issue that were years old. I think it is fixed now because I haven't seen it happen in months.
hooverd 4y ago
Wheels aren't licensed rather than owned and charged per revolution... yet.
- notpachet 4y ago
  Shit they stumbled onto my YC pitch deck
a1369209993 4y ago
> Would you rather do some library gluing, or reinvent a thousand wheels with every project? Wheels. Absolutely wheels. Library gluing is what gets us garbage like Electron that needs to die in fire. Imagine if a carpentry workshop gives a carpenter a bunch of IKEA kits and tries to conflate wanting to make furniture that isn't cost-cut prefabricated crap with insisting she can recreate all the other tools with just her whittling knife because it's in the 'true spirit of carpentry'. (Honestly, if anything, comparing Electron to IKEA is a insult to IKEA - there are cases where using IKEA is actually reasonable, they just aren't actually carpentry.) (You use libraries when it makes sense to use libraries, just like you use 2x4s when it makes sense to use 2x4s. Sometimes you can make the whole thing out of 2x4s, just like you can make a whole program out of: tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q but if you're just gluing (screwing?) 2x4s together, you're going to get bad results when you need something that's not a 2x4.)
nijave 4y ago
Ideally a healthy blend of both. Wheels where it relates to your companies core competences or there's a gap in the market. Glue for everything else (you don't need to invent an infrastructure provisioning solution unless you're and infrastructure provisioning companies--there's plenty of mature solutions). Other places like application libraries--it might make sense.

deathanatos 4y ago

I'd rather re-invent some wheels. The problem with VendorOps as I see it is that quite often the vendored "solutions" aren't solutions: they do not meet the requirements! Yet … they sort of get like 20% of the way there, so they get adopted nonetheless, and the devs toil away on trying to get glue code to push it the remaining 80% of the way. But if we had a system that we owned, then it could be adjusted to fit the requirements, elegantly. But we don't, so we can't. The other problem is the "Ops" part: vendor owned systems are opaque AF, and when something goes wrong, impossible to debug. Then you become a support ticket monkey, praying you can convince the powers that be on the other end that a. it is truly their stuff that's broken, not yours and b. we pay for it, so yes, you should support it. When a. or b. fails, then you end up writing yet more glue code to try to work around the bugs and outages that your vendor just doesn't give a shit about.

Aeolun 4y ago
We got random failures on our API gateway to lambda connections, and the answer we got back from the support agent was something like “automatically retrying on failure is industry best practice”. I just wanted to shout at them to fix their damn system, but of course we ended up implementing retries instead…
- agent281 4y ago
  For a while AWS Glue had an issue where the running job counter would permanently increment. This was a problem if you only wanted one copy of a job running. The advice support gave us was to increase the allowed count by one. I saw references to this issue that were years old. I think it is fixed now because I haven't seen it happen in months.

hooverd 4y ago

Wheels aren't licensed rather than owned and charged per revolution... yet.

notpachet 4y ago
Shit they stumbled onto my YC pitch deck

a1369209993 4y ago

> Would you rather do some library gluing, or reinvent a thousand wheels with every project? Wheels. Absolutely wheels. Library gluing is what gets us garbage like Electron that needs to die in fire. Imagine if a carpentry workshop gives a carpenter a bunch of IKEA kits and tries to conflate wanting to make furniture that isn't cost-cut prefabricated crap with insisting she can recreate all the other tools with just her whittling knife because it's in the 'true spirit of carpentry'. (Honestly, if anything, comparing Electron to IKEA is a insult to IKEA - there are cases where using IKEA is actually reasonable, they just aren't actually carpentry.) (You use libraries when it makes sense to use libraries, just like you use 2x4s when it makes sense to use 2x4s. Sometimes you can make the whole thing out of 2x4s, just like you can make a whole program out of: tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q but if you're just gluing (screwing?) 2x4s together, you're going to get bad results when you need something that's not a 2x4.)

nijave 4y ago

Ideally a healthy blend of both. Wheels where it relates to your companies core competences or there's a gap in the market. Glue for everything else (you don't need to invent an infrastructure provisioning solution unless you're and infrastructure provisioning companies--there's plenty of mature solutions). Other places like application libraries--it might make sense.