[jeffbee]

Really? The Pixel 8, my first Pixel, shipped without working USB webcam support, which was one of the advertised launch features. To actually get that feature you had to switch to the beta release track, which of course broke lots of the other things on the phone. Notable things that have been broken for a month or more on the beta track since I owned a Pixel 8 include tap to pay and the unlock screen.

[PUSH_AX]

We could do anecdotes all day. Unless there is hard data on how brittle or robust these devices are it all seems a bit pointless.

[ibash]

No, anecdotes are data. You can't just ignore customers and claim their experience isn't hard data.

One of my pet peeves is engineers making excuses for incompetence.

[glenstein]

>No, anecdotes are data

They're not good data, they're some of the worst. Your idiosyncratic one-off experience should be addressed, but not necessarily generalized from. I feel like this is an important, perhaps even the most fundamental prerequisite for information literacy.

[mardef]

Ok, so my Pixel 1, 3, 5, and 7 have had no problems.

Data shows 100% reliability then?

[tick_tock_tick]

I agree they are 100% data that's why we can say with absolute confidence there are no issues. (source my anecdotes)

[zoeysmithe]

tbf this is abusing the word anecdote a bit. Anecdotes are unreliable narratives and hearsay, not facts or data.

An anecdote is "I forgot to pray before bed last night and now I have a headache. See God is punishing me." and other people agreeing with this happening to them.

Saying, "here is a documented pixel bug that was released on day x but wasn't fixed until day y" is evidence and data.

Once its documented as a real bug then its no longer in the land of weird anecdotes.

How you categorize that is up to you. You can be dismissive of what that bug broke as an "unimportant feature" but its no longer an anecdote.

[PUSH_AX]

Good luck with that. Sure it's data, it's the worst possible data you could choose to make an informed decision. If you want to gain insight by selectively reported, highly biased reports of a tiny sample size, go for it.

[izacus]

So the fact that my iPhones wifi failed means that they're all terrible products and we shouldn't look at engineering practices like failure rate statistics?

Or do we just do that for brands we're not fanboys of like __true__ engineers?

[oxide]

anecdotal evidence is what I usually base my purchases on, which is why I've never bought a Google device after being burned (literally) by the Nexus 6P battery issues.

you can pretend it doesn't matter, but bad word of mouth is all it takes for me.

[digging]

> but bad word of mouth is all it takes for me.

That's fine, but it's also entirely different from saying that the phones are objectively unstable and bad for everyday use.

[Gigablah]

I have been burned twice by iPhone battery issues (specifically my iPhone X).

Battery started discharging rapidly, I got it replaced, barely a year later it’s dying again.

[hello_moto]

This is me + wife with Pixel 3 despite "Battery Saving" mode and killall apps.

The screen is eating up the battery like me drinking water on a hot California weather.

[webnrrd2k]

A quick search turns up problems, enough so that, as a consumer, I'd be concerned. Is that hard enough data to reach a conclusion in a major scientific journal? No.

Is it enough data so that, as a consumer looking to purchase one, I would be concerned? Probably.

Is it enough data that I'd expect some engineer at Google (or wherever) to pay attention and address? Certainly, I would expect some engineering team to pay attention to public forums and address issues as they arise. It doesn't seem to be happening. If these phones are supposed to be a flagship items, and I think it's reasonable to claim that they are, it's also reasonable to expect flagship support.

[lordnacho]

But who is going to have the data that we need to assess this?

The firm that has an interest in everyone thinking there's no data, and that we should withhold judgement.

There's not a lot of good choices here, either you assume that because there's no info, everything is fine, or you assume that the one guy complaining is one of many.

[seattle_spring]

I'm sure we could also find anecdotes of some iPhone users having features necessary for them blocked or non-functional. It does not mean that the vast majority of people cannot still use the device without incident as a "daily driver."

[jeffbee]

I used an iPhone from launch to the iPhone SE3 and I can't recall there ever being a feature printed on the box or hyped by Steve Jobs on stage that did not work out of the box, or that later stopped working.

[glenstein]

Here's one about battery life:

https://discussions.apple.com/thread/255046014?sortBy=rank

[SideQuark]

You must have had that single magic version of Apple Maps no one else got for a long time on release.

They lost the batterygate lawsuits, right? Guess you missed that fiasco that resulted in Apple paying out over half a billion. In this case Apple deliberately degraded previous user experiences on older phones, which means previous behavior (in this case performance) stopped working, done deliberately by Apple.

yes, it didn't go to zero, but it didn't do what it once did as decided remotely by Apple).

Apple also promised user data security, sold user data, and got hauled before Congress in 2011 for that. But I guess your user data was safe in offshore data silos.

I could go on, but I think your recall on iPhone downsides stopped working.

[Dylan16807]

The only thing they did on purpose was run too close to the limits of the battery.

The battery degraded because it was a battery, and the performance had to degrade along with it because of physics.

Apple didn't decide remotely to weaken performance. That performance was on borrowed time. What Apple did wrong was not making it clear upfront that the performance was on borrowed time and wasn't sustainable.

[SideQuark]

> The battery degraded because it was a battery, and the performance had to degrade along with it because of physics.

> Apple didn't decide remotely to weaken performance.

It's amazing when people just make crap up without even looking something as simple as this up. Apple lost the "batterygate" lawsuit because they specifically did slow down performance on old phone with an update.

A quote [1]: "Apple has agreed to pay up to $500 million to settle a class action lawsuit that accused the tech giant of slowing down older iPhones to encourage people to buy the latest model. Apple faced a wave of criticism -- and lawsuits -- after acknowledging in 2017 that its iOS software slowed down the performance of some older iPhones."

All the court docs [2]. Knock yourself out.

If you're going to shill, at least take a moment to google a claim before making up nonsense.

[1] https://www.cnet.com/tech/mobile/apple-to-pay-up-to-500m-to-...

[2] https://www.courtlistener.com/docket/6431809/in-re-apple-inc...

[Dylan16807]

Okay there's an asterisk on the "had to", which is "unless you want an unstable phone". There's plenty of evidence for that.

Apple lost because they did a bad thing, but I disagree with your characterization of what the bad thing was. In particular I will note that your quote says that they settled and what they were accused of, which is very different from a verdict.

[kaba0]

> They lost the batterygate lawsuits, right? Guess you missed that fiasco that resulted in Apple paying out over half a billion. In this case Apple deliberately degraded previous user experiences on older phones, which means previous behavior (in this case performance) stopped working, done deliberately by Apple

Let’s not share this absolute misinterpretation of what happened.

Apple fcked up big time on communication, that’s for sure, but it was an absolutely well meaning feature for an old device, lengthening their lifespan. They saw a bunch of random poweroffs due to degrading batteries not being able to output enough power to the CPU, and pushed an update that decreased the CPU clock down a bit. This of course degraded performance, and not having informed the buyers, making it a choice, they lost a lawsuit. But if they would actually do the communication well, it could have been an excellent positive PR, them fixing a bug for a 4 or so years device!

[SideQuark]

> Let’s not share this absolute misinterpretation of what happened.

Let's not spin what happened, which has concrete and irrefutable evidence. Here's all the court docs [1]. Apple got caught, most definitely did degrade performance without warning and on purpose, and certainly people at Apple knew some of those device owners would upgrade. That they spun it as a feature once caught is classic spin. Apple is no idiot at marketing - if they thought people would see this as positive PR, they would have announced it and touted it. They did not. The 7 million+ pages of Apple discovery made all this clear. This is why Apple settled for a half billion - they were certainly going to get hammered in court.

Read the court docs, not Apple PR.

[1] https://www.courtlistener.com/docket/6431809/in-re-apple-inc...

[refulgentis]

So you think there should be more testing so the testing track is stable?

I worked on Pixel, left Google in October. I agree vehemently with what you're saying, its just, you're barking up the wrong tree on a couple different levels, the easy one above, and a more difficult one below.

Management did what you wanted a few years back, #1 and #2 and #3 priorities were "stability above all else" since Pixel 6.

This unfortunately didn't do anything in practice, other than enable newly minted middle managers to punch down, hoard work[1], and hide poor decision making and lying easily.[2] Net negative effect on product of course.

What managers wanted to legislate was "care about your features", but I observed over years that you simply can't enforce that. Ironically, given the above behavior from the new management layer, people got more detached. Unit test coverage went up, I'd bet, which is also a lesson in unit tests have significantly diminishing returns. E2E tests are hard and flaky, but they pay 100x dividends in these situations.

What you want to legislate is the truffle hunting that lowest level management does is bad. i.e. say we can definitely do whatever pet thing some guy 3 levels up says we need to copy from iOS this year. Then, hold it back because it's not done, but still announce it. Then, layer on a special process to get you on the betas to get the feature you thought you were buying. All of this keeps each individual happy and yet, remarkably, leads us directly back to the initial situation we were trying to fix.

From all this, you can also derive why things only launch, and never improve (tl;dr: management has 0 incentive to do anything other than latch onto the latest vague ask / iOS copying from above)

[1] Estimate everything takes 3-5x engineers it did 3 years ago. it's a huge win: I'm managing this team because I did it myself 3 years ago, so this makes clear what a talented engineer I was/am. When I solely listen to the vague asks from people 3 steps above, they'll want to give me the headcount I need to get their pet project done, so this gives me more reports. My compensation scales with report count. And if the estimate is questioned in any depth, well, we're making sure we have enough to deliver this Priority™ at high Quality™. Also, no one is going to question it anyway, my manager made me a manager because they trust me.

[2] it's very easy to work around blatant irresponsibility by flipping it into "the guy lower on the totem pole is insufficiently committed to quality and collaboration [taking forever to do anything]"

[jeffbee]

Yes, I think the dogfood stage before the beta release should be more thorough. For the record, I was also adamant about this while I still worked at Google. Google, especially Android, is way too eager to release to beta. You should not release to beta until you have stopped generating new defect reports in dogfood. If you do, you just annoy the beta testers and get a huge number of duplicate reports. That is exactly what happened this year with the lockscreen bug. If anyone in dogfood had even touched the phone once the problem and its severity would have been obvious. And breaking Wallet generated 13000 duplicate reports, breaking a core use case for beta users.

[refulgentis]

That's actually the policy as I understood it, though, it was being enforced starting in an OS cycle, and I was only there for a month of it. When I think of institutionalized maladaptive dysfunction, I think of the lock screen.