We used Parse, and (contrary to your suggestion) it helped us get to market much slower and much more expensively. We experienced a hilarious amount of downtime, and hundreds of engineering hours that could have been spent developing features for our users or improving our services were spent working around fatal bugs in Parse, which were usually not manifesting on all instances, which made it very difficult for the Parse team to diagnose them.
Fixes for Parse bugs were usually not forthcoming from the Parse team---and when things were fixed, more often than not the fix was reverted within a week because it caused something even worse.
For the first six months of our time using them, Parse would only report downtime post facto and backdated by a day. “F@#$k Parse” was perhaps the most frequently uttered phrase among all of us in our douchebag Mission district headquarters. What a life.
All the time, push notifications inexplicably stopped working for hours at a time---we were running a daily sales app, and this really killed us. It ruined dozens of auctions and pissed off tons of our users. But what's even worse? Parse made my life a living hell for a year, and I'm glad they're gone.
Ran into the exact same issue when using Parse. I was working on an app that
operated primarily through push notifications. The push notification downtime
was horrible -- I remember having to get on calls with clients apologizing
profusely for the downtime. We were also paying Parse an absurd amount of money
for extra reliability, which didn't seem to help much.
I never heard people talking about the difficulty of moving off of Parse,
especially in mobile clients that were developed with the Parse SDK. I spent a
ridiculous amount of time getting Parse synced with our custom backend so old
clients wouldn't break.
Final thing: debuggin. For nearly any issue, a half-assed solution---often not
usable in production---by one of their staff was buried deep into their forums.
> We were also paying Parse an absurd amount of money for extra reliability, which didn't seem to help much.
We were also hooked into the same scam!
> For nearly any issue, a half-assed solution---often not usable in production---by one of their staff was buried deep into their forums. Super painful.
Haha, well put. They always directed people to their pathetic "support forum", where one of their staff would propose a criminally bad "solution" to a problem, which no self-respecting engineer could even sanction putting into production.
Interesting. Sounds like Parse wasn't nearly as mature as they made themselves out to be. I'd have expected at least PaaS levels of stability—by, at the very least, pinning each client to a particular API version with guaranteed semantics until they choose to shift to making requests on higher-versioned equivalents of each API resource.
A thought: if "Parse" had originally just been this open source Parse Server offering, and you had taken that and plopped it on e.g. Heroku, would that have been a better deal for you? Seems like "apply FOSS to PaaS to get BaaS" wouldn't have been that much more hassle, operations-wise; and you would have been able to upgrade the backend only when you liked, rather than having it mutated out from under you.
So, I would say, if Parse had been this Parse Server product from the start, that would have been a lot better! But there wasn't really any need for such a thing at my company. We had to use Parse for incestuous "YC alum" reasons---we did not have a technical need for it.
Haha, well funny you should mention it---management were also encouraging me to look into using firebase for something too, but I put the kibosh in it because we had had so much trouble with Parse. The truth is, we had no need for any of these products (even though I have heard firebase to be way better than parse); we needed to get serious and just write a little API server + postgres database and toss it on Heroku.
Hey I'm not sure what contract you're referring to, but from a Parse point of view I think you should feel free to go into details about what didn't scale for you about Parse. There is definitely a tradeoff between "ease of use" and "ease of scaling" in many places and using a "backend as a service" won't be the right thing for everyone. I would rather that people be honest and open about what works well and what doesn't.
Hey there—I've done my best to be as honest and up-front about my experience with Parse. (I apologize if it has seemed overly harsh; but it ate its way into many different parts of my life and really made my year difficult.)
But I can't really go into much detail about what we did at our company and why we did it, because when I left, I took a severance on certain terms. And in any case, it's not really appropriate to drudge up old arguments, and I have no interest in making comments that might make it more difficult for the people I worked with to do what they want to do now.
Ha! Good question. I wrote this comment with out much thought really. He CAN be... maybe "stern" is a better word? He's generally totally professional, nice and friendly, but he doesn't let people push him around, and he pushes back when he needs to. He's "well rounded", how's that?
I imagine it's just a phrasing thing, he probably means someone that sticks up for themselves. I've seen a lot of very effective engineers get bogged down in bad work because they wouldn't push back on ideas/projects that were obviously not great ideas.
Politics isn't something to be studied "objectively", where views are right or wrong on their own merits (or worse, some pseudo-"empirical" measure). There is no "null theory" for politics; all political engagement starts from some political theory or method of analysis.
So this so-called "mood affiliation" isn't a fallacy at all, it's the identification of a speaker's political theory. Pretending that you don't have such a theory (or that yours is "objective" or "neutral") won't make it so!
My political theory includes as a major idea that people dying when they don't have to is typically bad.
Based on this, I judge certain environmental problems to be significant. Someone else, motivated by the belief that environmental problems are overblown, denies that they are. Mind you, this person doesn't deny that we should try to save lives. They just deny the facts about what's happening. 
There are (contentious!) philosophical theories on which neither one of us is being objective, but, C'MON, whatever philosophical points you might make, you have to acknowledge a very real sense in which one of us is just reasoning badly.
 And to forestall any knee-jerk reactions, yes, it is sometimes the case that people assume a potential environmental problem is a disaster because of the opposite sort of mood affiliation. Which is more common isn't even the point.
If you're against involuntary death, shouldn't your top priority be curing aging? The vast majority of deaths on this planet are due to age-related illnesses. Not accidents, not violence, and certainly not environmental catastrophes.
Possibly! We'd both have to spell out a lot of details to have that argument. I'm not the one to have it either, because I don't know how plausible it is that we can really solve aging anytime soon.
But I'd say it's not super-relevant to the argument at hand, since the person who we're discussing doesn't say "these environmental problems are less important than aging" but just denies the specific harms are happening on the scale they are.
Edit: crap, left out a not. "It's not super-relevant."
Or more generally, people could argue about costs of different ways of mitigating deaths because maybe some non-environment-related issues are "cheaper" or "better" in some way to mitigate. There's not just the question of what causes the most deaths, but also the question of what could be done about it and how.
And people do have lots of ideas and arguments about those questions, like effective altruists' ideas about cheap medical interventions.
That's true in the sense that politics is war by other means. But the materials of politics, like war, can to some extent be studied objectively. The forces that make this hard—e.g. tribal identification—impede other forms of objective study too, though to a lesser extent.
This is so completely wrong. The most exciting work happening in systems, networking, programming languages, crypto, computer architecture, mobile, and many other subfields of computer science is highly relevant to industry and very interesting academically.
I do pure type theory, semantics, proof theory & intuitionistic mathematics. Very little of this will find a home in industry (at least, not for several decades). Industry has historically been incredibly resistant to 100% of the things I'm interested in, and I don't blame them!
But it's not just the hard & expensive stuff that they are resistant to. Even the "easy" stuff (like adopting a programming language designed by the professionals instead of the amateurs) they won't do.
I build interactive proof assistants. But I'm not pushing their applicability to industry, and I don't expect them to be relevant to industry (for a long time at least). Why? Because it's too expensive. Formal verification in type theory MAKES NO ECONOMIC SENSE; ask anyone who's actually ever done any industrial verification, and you will find out what tools they are using, and it has nothing at all to do with the area of research I'm involved in. This is because there are inherent trade-offs in every technique, and industrial use-cases tend to prefer a certain set of trade-offs, and I prefer a different one.
But it's a fascinating topic, and something that I'm preparing to devote the next several years of my life to. And I can safely say that a meteorite will more likely destroy Manhattan than will any of my computer science research be of widespread relevance to industry.
So, no, I totally disagree with everything you have said.