They’ve always been this way. Eventually the OS will get noticeably shitty, then it will be embarrassing, then they’ll do a cleanup sprint and fix most of them.
When I worked at a (formerly state monopoly)telco around 2000 it would happen that an inspector would come in and look for any warning lights on equipment. If you were around you'd better know how to fix it right away.
These days that kind of attention to detail is long lost in the sea of competition and cost cutting. But issues tend to build up now and cause really expensive megaprojects to really fix them.
I could imagine software engineering followed a similar trajectory.
It used to be that even-numbered releases fixed bugs and stabilized the OS, with notable features coming in odd-numbered releases. Now they don’t care. Unifying iOS and macOS has become the goal, and probably some PMs are getting nice promotions thanks to that. The golden stability of macOS (a la Snow Leopard) is gone. Now I get random reboots every other week, so I keep a tight Time Machine schedule.
> It used to be that even-numbered releases fixed bugs and stabilized the OS, with notable features coming in odd-numbered releases.
That's a myth. The stability comes from minor bug fix updates, not from major updates. And the even-numbered Mac OS X 10.4 Tiger for example had huge new features, such as Spotlight, Dashboard, VoiceOver, etc. Mac OS X 10.2 Jaguar also had huge new features.
I stand corrected, and I’ll rephrase it as “it used to be that every now and then Apple released a version of macOS with notable fixes and small improvements.”
I’m not downplaying how much work is going into crazy features that millions probably like. But I make software, and I’m tired of how macOS is now marginally less annoying than trying to maintain an Arch Linux setup.
I went through a period of burnout at my work during Covid.
I was in Canada at the time though and our lockdowns lasted through almost 2 years though (unlike many places in the US that either did not do lockdowns at all, or did only for a very short period).
In any case during this time period of being stuck, isolated and inside most of the year I had little else to do but throw myself into my work. Today I have the same job and a much healthier balance but that’s mostly due to a really good manager that noticed and helped me out.
> Mac OS X had a yearly release cycle in the beginning if I remember correctly.
That's not correct. Here are the # of months since the previous Mac .0 release:
10.1.0 6
10.2.0 11
10.3.0 14
10.4.0 18
10.5.0 30 (delayed due to iPhone)
10.6.0 22
10.7.0 23
(Steve Jobs resigns)
10.8.0 12
10.9.0 15
10.10.0 12
10.11.0 11
10.12.0 12
10.13.0 12
10.14.0 12
10.15.0 12
This was a logical progression until 10.8. The fundamental software development principle is that immature software is easier to improve, because there's a lot of low-hanging fruit — glaring bugs and missing features — whereas mature software is harder to improve and easier to accidentally break. That's why major updates should come more slowly as the software matures over time.
It's no coincidence that Tiger and Snow Leopard are viewed as high points in Mac OS X quality and stability. It's not because of the .0 releases, which were very buggy like any .0 releases; it was because they ultimately became very stable after many many months of minor bug fix updates with no major updates (30 and 23 months respectively).
Also worth mentioning: major Mac OS X updates used to cost $129. Now they cost $0. You get what you pay for. Now users are pushed into updating whether they like it or not. You might wonder whether the principle starts to apply: if you're not the customer, you're the product. After all, Apple has been transitioning into a so-called "services" company. They'd rather sell yearly "subscriptions" (more accurately, rentals) than major OS updates.
> In my opinion, the drop in quality was probably at least also related to Steve Jobs‘ death.
This may be true, but note that the change in OS release schedule coincides with the death of Jobs. Mac OS X 10.8 was the first post-Jobs release and also the start of the annual schedule.
Thanks for the details. Just to be clear, I‘m certainly not in favor of the yearly release cycle. Or rather, I‘m not in favor of any primarily calendar driven release cycle.
FWIW, the update from (checks notes for the naming) Ventura to Sonoma is pretty much just a bugfix release, there were almost no noteworthy new features.
There's no such thing as a major bugfix release. Every major update introduces more bugs than it fixes, and Sonoma is no exception to that hard rule. Which bugs were fixed? I've personally filed multiple new bugs against Sonoma.
I wrote about this in my previous comment: "It's not because of the .0 releases, which were very buggy like any .0 releases"
I have been at a company that transitioned from normal release cycles to arbitrary yearly release cycles. Every year became a literal race to fix issues, improve existing features, and add new features. It was a gigantic mess. The yearly release cycle only really gives a few months to do all of that, because the other months are doing integrations, testing, and bug fixes to get the release out the door.
I can certainly see that if the emphasis on new features greatly outweighs that of bug fixes and improvements, then you can extend the implementation months for larger features because you can just bleed the bug fixes and improvements into next year's release. But then that year's feature set takes precedence and dept accumulation occurs.
My own experience with macOS is that it stopped "just working" a decade ago Apple stopped caring about it and poured everything into iOS. And then this is exacerbated by today's mode of operating by just treating features like they're free and frequent release cycles.
It's not the release cycle per say, but the need to pack new features in each cycle for marketing and sales.
A regular release cycle that focuses on security, stability and incremental improvements, is fine as long as there isn't a need to constantly push new features in.
In my experience engineering teams usually always want to fix issues like this. However, this typically come down to something leading to either pressure to ship features relenting and engineering being allowed to clean up debt or awareness of quality issues increasing. Seems like burnout would be a factor if Apple tried to fix it but failed or took forever.
Oddly, being paid more and being safer while others get worse can actually contribute to burnout. Comraderie and morale matter.
Burnout is more about a disconnect and dysregulation between workload/emotional regulation/stress/morale than it is about any one of those factors.
As anyone who has burnt out at a super boring job, or a pointless but high stress job can attest.
A high stress, high risk, job that matters, keeps someone interested, and someone can take breaks from is much less of a burnout risk than one that someone can’t see matters , or they don’t grow in, regardless of the stress level or ability to take breaks from.
Thank you for the reminder. This random developer (not from Apple) does feel some exhaustion, but I have it lucky compared to some other folk and should be grateful for that. Hoping those other folk who have it worse will have some relief too...
