Hacker News new | ask | show | jobs
by refulgentis 670 days ago
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]"

1 comments

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