5 ms·

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 goe

by eppp 1y ago

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...

IggleSniggle 1y ago
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.
- Wilduck 1y ago
  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.
  - eppp 1y ago
    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.
    - hobs 1y ago
      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 :)
  - nailer 1y ago
    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.
- eppp 1y ago
  Perhaps they didn't want to build it themselves and took into account the other risks like the company folding?
  - echelon 1y ago
    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.
- JackFr 1y ago
  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.
  - IggleSniggle 1y ago
    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.
    - saghm 1y ago
      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.
      - IggleSniggle 1y ago
        It doesn't, and at least in this thread, I don't think anyone was saying it did.
        saghm 1y ago
        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.
- guappa 1y ago
  That's one point of view. Maybe from the other side the worst one wasn't the in-house solution.
riehwvfbk 1y ago
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.
- tsimionescu 1y ago
  Why would adding an external chat solution to an app that is not about chat make the developers of the app look redundant?

by eppp 1y ago

IggleSniggle 1y ago

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.

Wilduck 1y ago
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.
- eppp 1y ago
  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.
  - hobs 1y ago
    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 :)
- nailer 1y ago
  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.
eppp 1y ago
Perhaps they didn't want to build it themselves and took into account the other risks like the company folding?
- echelon 1y ago
  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.
JackFr 1y ago
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.
- IggleSniggle 1y ago
  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.
  - saghm 1y ago
    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.
    - IggleSniggle 1y ago
      It doesn't, and at least in this thread, I don't think anyone was saying it did.
      - saghm 1y ago
        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.
guappa 1y ago
That's one point of view. Maybe from the other side the worst one wasn't the in-house solution.

riehwvfbk 1y ago

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.

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