> We were constantly faced with product leaders (VPs of Product, CPOs, PMs, etc.) who were very excited about adding Cord to their existing product. They saw the value unambiguously. And then we’d get to the dev team and face a stonewall of NIH syndrome alongside a clear preference for building it all themselves, even when that meant shipping a vastly less-useful product to their end users.
From the other side, this looks like "management signed up for some flashy product based on marketing, but it turned out to be useless". Not recognising that seems like a substantial blind spot.
It would be interesting to hear from anyone who evaluated Cord and decided not to use it. I wonder if the risk that the company might fold entered into the decision.
Still, excellent of them to have open-sourced it; it superficially looks like they've put a lot of effort into making it usable.
I find that an uncharitable take to assume lack of usefulness.
It’s more likely literally what the author says - getting engineers onboard for something they themselves didn’t choose is difficult. I’ve been in the same position - lots of buy in from leadership / solving a real problem and providing real value. Then it takes months to implement due to having to corral a dev team who simply doesn’t care about your integration.
Most employees are unmotivated and mediocre-at-best, across every role and industry because most people are (rightly) just showing up to get paid. Engineers are no different, we are not special. Most engineers do not have the incentive to go out of their way to improve their product when keeping this as-is is easier for them. Regardless of whether the OPs product is good, almost all of the engineer opposition would come from engineers not wanting to deal with integrating some new thing that non-engineers want because it’s more work.
If you think most engineers are evaluating things based on the value it’ll drive for their product, you’ve lived a lucky career (and long may it continue).
Same impression, after a skim of the Github. Looks like a net complexity add in most cases, if I understand its Readme correctly.
Due to the software culture I've been exposed to, especially in web-dev, I am cautious about any level of indirection added by third parties. They may seem like a value-add to first-order, but when managed in the context of a larger system, tend to make performance worse, debugging more difficult, and modifications high-inertia. Not as a principle, but based on observations.
For example, When I see text like this: > With pre-built components for chat, presence, and notifications, as well as fully customizable UI primitives, Cord enables rapid implementation of sophisticated, in-app collaboration tools.
my pattern-matching brain thinks This is probably going to be slow, require the user to download a large amount of data, and may or may not reduce code required to implement, and will make customization and modification tedius. Maybe this isn't true for this particular library, but it seems to be a good rule, currently.