Hacker News Reader

Comment by eppp | Hacker News Reader

The in house developers raised their hackles and had reservations about using the product even in the face of perceived inferior solutions. The product then goes out of business... The irony of this story...

View on HN

The customer's in-house developers raised their hackles and had reservations about using the product, even though the customer's in-house solutions were terrible, because the customer's in-house developers wanted to build it themselves. I'm not sure if the article wasn't well worded and you misunderstood, or if it's me who doesn't see the irony.

The irony is that a valid reason for in-house developers to not want to use an external product is concern about the long term support availabilty for that external project. You could make a case that this product shutting down is proof the in-house developers were right not to trust it.

I don't think that's totally fair in this case, since it seems they open sourced their software. But also, in general, I think NIH syndrom gets a bad rap. Sometimes a "worse" solution you control really is more reasonable compared to a technically superior solution made by an external company.

Ive been doing this for 20 years and I have had to do several major migrations due to vendors doing all sorts of stupid things. Millions of dollars and so so many hours completely unproductive because a commercial off the shelf product was 'cheaper' to buy initially.

Feeling it :) Currently in day two of an outage with almost no vendor response for my entire platform because it was "the cheaper option" :)

Every quarter during budgeting I have politely pointed out this inferior service costs us a lot of money and sucks at support as well, and every time its considered not a priority.

Today its a priority :)

This exactly happened for the same product a few years - a real time push company called Pusher folder (or killed its major product) and everyone using it had to migrate.

Perhaps they didn't want to build it themselves and took into account the other risks like the company folding?

Or the cost being 10x'd after they come to depend on it.

That certainly hasn't ever happened to us before.

Every external { tool, vendor, SaaS, platform } is a potential risk. You don't want to eat a year of unplanned costs and a quarter or more of engineering hours of migrating off.

One of the reservations the customer likely had is "will this company be around in X years?" The inferior home-grown product will continue to be supported.

Thank you for clarifying for me so elegantly. That self fulfilling prophecy does have a sense irony to it, especially given that the code is open sourced.

So basically, now the developers could decide to use it for free if they wanted? Either they will, and they'll have saved their company a lot of money, or they won't, because the traditional issues they had with it are still there. I'm not sure how either of those ends up making the developers look like they made a bad decision.

It doesn't, and at least in this thread, I don't think anyone was saying it did.

Yes, the current state of the thread now that it's been too long for any of the comments to be edited further certainly doesn't look like anyone was saying it.

That's one point of view. Maybe from the other side the worst one wasn't the in-house solution.

Well, this is a very one-sided take. Imagine being a dev tasked with evaluating a product that makes you look redundant and also costs the company license fees in perpetuity. Whereas building a homegrown solution ensures that you keep your job, and get to look like a rockstar who saved the company money. Gee, I wonder which one the devs picked.

Why would adding an external chat solution to an app that is not about chat make the developers of the app look redundant?

Reply on news.ycombinator.com