3 ms·

I don't think that's quite right. Snow Leopard was a lot of changes to a lot of the OS code base and wasn't great out of the gate, taking multiple dot releases,

I don't think that's quite right. Snow Leopard was a lot of changes to a lot of the OS code base and wasn't great out of the gate, taking multiple dot releases, like all large-scale software updates do, to stabilize and bugfix enough to be "good." There is no silver bullet, just a lot of lead ones and the answer to Apple's quality problem is to begin baking QA back into the process in a meaningful way after letting it atrophy for the last decade or so. Hire more humans and rely less on automation. Trust your developers, QA, and user support folks and the feedback they push up the chain of command. Fix bugs as the arise instead of assigning them to "future" or whatever. Don't release features until they're sufficient stable. This is all basic stuff for a software company, stuff that Apple seems to have forgotten under the leadership of that glorified accountant, Cook.

1over137 2y ago
Why do any of that? What they're doing has made them infinitely rich, and that's all that matters. /s
- blitzar 2y ago
  Being infinitely rich might also be the cause of the problem.
- asadotzler 2y ago
  Well, you can only win playing the stock market (Wall St. is Cook's only real customer) for so long while your products deteriorate. Financializing Apple and eliminating its technical prowess opens the door for the someone else with contemporary technical strength to take Apple's users.
bigdubs 2y ago
Adding to this, a solution might be enabling continuous releases and leaning into release channels could help in terms of getting more out to users. In practice it's a challenge because the OS bundles a lot of separate things into releases, namely Safari changes are tied to OS changes which are tied to Apple Pay features which are tied to so on and so on. It would require a lot of feature flagging and extra complexity which may reduce complexity. Another way is to start un-bundling releases and fundamentally re-thinking how the dependency graph is structured.
- dcow 2y ago
  I think they’re painted into a corner with WWDC. Everything has to be a crowd pleasing brain busting wow drop each year. I’m certain there are teams that design their entire workflow around the yearly wwdc. It honestly feels like an executive leadership problem to solve.
  - jacobgkau 2y ago
    If that is a significant part of the problem, then moving WWDC from an in-person keynote attended mostly by nerds and glanced at by the media to an overproduced movie geared at the media and ordinary consumers first probably didn't help. They could've gone back to a stage presentation after COVID, but some of that transition had already been happening prior to that (I recall an increase in how many jokes/bits they were doing in the late 2010's, although that could just be my perception).
computerdork 2y ago
Appreciate the sentiment, but in my humble opinion, seems like they should lean into creating even better automated testing, because adding all the new bugs to their suite of automated tests would be a more certain way to decrease their chance of happening again. But, in a sense, this still incorporates your idea, because the devs and QA must be given the mandate of finding these bugs, and also towards making the automated tests cover the bug's related test cases (as well as charged with improving the test code itself, which is often in a mediocre state in most code bases I've seen at least).
- asadotzler 2y ago
  Sure, more and better of everything, with engineering, including QA, calling the shots on what's sufficient to ensure great quality.
quitit 2y ago
I think some people would be surprised how effective reaching out to apple is for squashing bugs. Three times now I've been assigned an engineer to pin point the bug I was experiencing, after which it was fixed in the next dot release. By all means people should complain on forums (why not?), but a forum post complaining about some years-old bug isn't going to be anywhere near as effective as contacting apple's support or filing a bug report. I'm not a developer, I'm just a regular user - so if I can get all this special treatment, so can you.
- tiltowait 2y ago
  Interesting. Apple podcasters frequently rant about what a black hole Apple's Radar bug system is. We're talking hours-long rants in some cases. Luck of the draw, maybe? I'm not doubting you, just surprised to read it. (It feels similar to how those same podcasters absolutely blast Apple Intelligence, while non-tech users I've heard from seem to love it.)
- plorkyeran 2y ago
  Yes, I am very surprised to hear that you've had such success with reporting bugs to Apple. That is very unlike my experience. I've had exactly one macOS bug that I reported fixed, and that required going to a WWDC lab, talking to a person on the relevant team in person, and having them dig the bug report out of the backlog for a completely unrelated team that it was incorrectly assigned to.
- eviks 2y ago
  They would be surprised because it's not true, those years-old bugs in the forums have been reported many times to the official bug tracker, with reference number sometimes posted in those very forums.
- noname120 2y ago
  You must be the lucky one, because other people have had horrible experiences with Apple’s Feedback Assistant: https://news.ycombinator.com/item?id=38164735 https://news.ycombinator.com/item?id=38164735
ninkendo 2y ago
> the answer to Apple's quality problem is to begin baking QA back into the process in a meaningful way after letting it atrophy for the last decade or so. As a former Apple employee of 13 years: Apple knows about the bugs. QA isn’t the problem. A lot of people complain that their radar for some obvious bug isn’t getting noticed, and conclude that Apple must not be QA’ing, or not dogfooding their own product. This isn’t the case at all. I guarantee the bugs you care about are well known, and QA has already spotted them. The reality is, they just don’t care. The train leaves the station in September. You’re either on it or you’re not. If you spent the year rewriting some subsystem, and it’s July and you have this huge list of bugs, there’s a go/no-go decision, and the answer is nearly always “go” (because no-go would mean reverting a ton of other stuff too, and that carries its own regression risk, etc.) So instead there’s just an amount of bugginess that’s deemed acceptable. And so the software is released, everybody slaps high-fives, and the remaining bugs are punted to next year, where they will sit forever, because once we do one release with a known bug, it couldn’t be that important, right? After all, we shipped with it! Future/P2, never to be seen again. An attempt was made to remedy this by pushing deadlines earlier in the cycle, to make room for more QA time, but that just introduced more perverse incentives: people started landing big features in later dot-releases where there’s less scrutiny, and even more tolerance for bugs. The honest answer is that Apple needs to start giving a damn about the quality of what they’re pushing. As Steve once said at a pretty famous internal meeting, “you should be mad at your teammates for letting each other down like this”. And heads need to roll. I can only hope that they’re realizing this now, but I don’t feel like the culture under Tim works this way. People’s feelings are way too important, and necessary changes don't get made.

1over137 2y ago

Why do any of that? What they're doing has made them infinitely rich, and that's all that matters. /s

blitzar 2y ago
Being infinitely rich might also be the cause of the problem.
asadotzler 2y ago
Well, you can only win playing the stock market (Wall St. is Cook's only real customer) for so long while your products deteriorate. Financializing Apple and eliminating its technical prowess opens the door for the someone else with contemporary technical strength to take Apple's users.

bigdubs 2y ago

Adding to this, a solution might be enabling continuous releases and leaning into release channels could help in terms of getting more out to users. In practice it's a challenge because the OS bundles a lot of separate things into releases, namely Safari changes are tied to OS changes which are tied to Apple Pay features which are tied to so on and so on. It would require a lot of feature flagging and extra complexity which may reduce complexity. Another way is to start un-bundling releases and fundamentally re-thinking how the dependency graph is structured.

dcow 2y ago
I think they’re painted into a corner with WWDC. Everything has to be a crowd pleasing brain busting wow drop each year. I’m certain there are teams that design their entire workflow around the yearly wwdc. It honestly feels like an executive leadership problem to solve.
- jacobgkau 2y ago
  If that is a significant part of the problem, then moving WWDC from an in-person keynote attended mostly by nerds and glanced at by the media to an overproduced movie geared at the media and ordinary consumers first probably didn't help. They could've gone back to a stage presentation after COVID, but some of that transition had already been happening prior to that (I recall an increase in how many jokes/bits they were doing in the late 2010's, although that could just be my perception).

computerdork 2y ago

Appreciate the sentiment, but in my humble opinion, seems like they should lean into creating even better automated testing, because adding all the new bugs to their suite of automated tests would be a more certain way to decrease their chance of happening again. But, in a sense, this still incorporates your idea, because the devs and QA must be given the mandate of finding these bugs, and also towards making the automated tests cover the bug's related test cases (as well as charged with improving the test code itself, which is often in a mediocre state in most code bases I've seen at least).

asadotzler 2y ago
Sure, more and better of everything, with engineering, including QA, calling the shots on what's sufficient to ensure great quality.

quitit 2y ago

I think some people would be surprised how effective reaching out to apple is for squashing bugs. Three times now I've been assigned an engineer to pin point the bug I was experiencing, after which it was fixed in the next dot release. By all means people should complain on forums (why not?), but a forum post complaining about some years-old bug isn't going to be anywhere near as effective as contacting apple's support or filing a bug report. I'm not a developer, I'm just a regular user - so if I can get all this special treatment, so can you.

tiltowait 2y ago
Interesting. Apple podcasters frequently rant about what a black hole Apple's Radar bug system is. We're talking hours-long rants in some cases. Luck of the draw, maybe? I'm not doubting you, just surprised to read it. (It feels similar to how those same podcasters absolutely blast Apple Intelligence, while non-tech users I've heard from seem to love it.)
plorkyeran 2y ago
Yes, I am very surprised to hear that you've had such success with reporting bugs to Apple. That is very unlike my experience. I've had exactly one macOS bug that I reported fixed, and that required going to a WWDC lab, talking to a person on the relevant team in person, and having them dig the bug report out of the backlog for a completely unrelated team that it was incorrectly assigned to.
eviks 2y ago
They would be surprised because it's not true, those years-old bugs in the forums have been reported many times to the official bug tracker, with reference number sometimes posted in those very forums.
noname120 2y ago
You must be the lucky one, because other people have had horrible experiences with Apple’s Feedback Assistant: https://news.ycombinator.com/item?id=38164735 https://news.ycombinator.com/item?id=38164735

ninkendo 2y ago

> the answer to Apple's quality problem is to begin baking QA back into the process in a meaningful way after letting it atrophy for the last decade or so. As a former Apple employee of 13 years: Apple knows about the bugs. QA isn’t the problem. A lot of people complain that their radar for some obvious bug isn’t getting noticed, and conclude that Apple must not be QA’ing, or not dogfooding their own product. This isn’t the case at all. I guarantee the bugs you care about are well known, and QA has already spotted them. The reality is, they just don’t care. The train leaves the station in September. You’re either on it or you’re not. If you spent the year rewriting some subsystem, and it’s July and you have this huge list of bugs, there’s a go/no-go decision, and the answer is nearly always “go” (because no-go would mean reverting a ton of other stuff too, and that carries its own regression risk, etc.) So instead there’s just an amount of bugginess that’s deemed acceptable. And so the software is released, everybody slaps high-fives, and the remaining bugs are punted to next year, where they will sit forever, because once we do one release with a known bug, it couldn’t be that important, right? After all, we shipped with it! Future/P2, never to be seen again. An attempt was made to remedy this by pushing deadlines earlier in the cycle, to make room for more QA time, but that just introduced more perverse incentives: people started landing big features in later dot-releases where there’s less scrutiny, and even more tolerance for bugs. The honest answer is that Apple needs to start giving a damn about the quality of what they’re pushing. As Steve once said at a pretty famous internal meeting, “you should be mad at your teammates for letting each other down like this”. And heads need to roll. I can only hope that they’re realizing this now, but I don’t feel like the culture under Tim works this way. People’s feelings are way too important, and necessary changes don't get made.