> One solution is to treat startup cycles as a resource similar to e.g. size or backend servers.

The only way to achieve performance metrics in a large org IMO.

Google Search is still fast because if you degrade p99 latency an SRE will roll back your change. Macbooks still have good battery life because Apple have an army of QA engineers and if they see a bump on their Ammeters that MacOS release doesn't go ahead.

Everything else (especially talking about "engineers these days just don't know how to write efficient code") is noise. In big tech projects you get the requirements your org encodes in its metrics and processes. You don't get the others. It's as simple as that.

Never worked at MS but it's obvious to me that the reason Windows is shit is that the things that would make it good simply aren't objectives for MS.

As an ex-Microsoft SDET who worked on Windows, we used to test for those things as well. In 2014.

Then Microsoft made the brave decision that testers were simply unnecessary. So they laid off all SDETs, then decided that SDE’s should be in charge of the tests themselves.

Which effectively made it so there was no test coverage of windows at all, as the majority of SDE’s had not interacted with the test system prior to that point. Many/most of them did not know how to run even a single test, let alone interpret its results.

This is what Microsoft management wanted, so this is what they got. I would not expect improvement, only slow degradation as Windows becomes Bing Desktop, featuring Office and Copilot (Powered By Azure™).

Makes perfect sense. It recently became clear to me (e.g. [2]) that it's not a cohesive concept but to me personally this is the meaning of POSIWID [1].

Basically making Windows a good desktop OS is not in any meaningful way the "purpose" of that part of MS. The "purpose" of any team of 20+ SWEs _is_ the set of objectives they measure and act upon. That's the only way you can actually predict the outcomes of its work.

And the corrolary is that you can usually quite clearly look at the output of such an org and infer what its "purpose" is, when defined as such.

[1] https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_w...

[2] https://www.astralcodexten.com/p/highlights-from-the-comment...

Then the OS team will fight back with options to disable all of these startup things. Like the Startup tab in Windows Task Manager with an "impact" column and easy button to disable annoying startup programs. It's interesting to even see it play out within the same company.

The only impact values I see on my home machine are "Not measured" and "None".

The solution is simple: New OKRs and KPIs in the next cycle reversing some of the current ones, then new bonuses for reaching them. Repeat.

“I could do this all day!”

Office codebase is soon going to probably be older than most people that work on it.

That could already be the case. The initial release is from 1990, so the codebase is at least 35 years old.

I don't have a good guess for the average age of software developers at Microsoft, but claude.ai guesses the average "around 33-38 years" and the median "around 35-36 years old".

"but claude.ai guesses"

To my ears this is the equivalent of "some guy down the pub said", but maybe I am a luddite.

You're not a luddite, they disclosed it because you're _supposed_ to take it with a grain of salt

Office was released in 1990, but Excel in 1985 and Word in 1983.

I'm told from MS friends that there are still files with the intact 1987 changelog in Word; as well as workarounds for dot matrix printers that were released 40+ years ago.

Also, the Office codebase is significantly larger than Windows (and has been for a while), that was surprising to me.

make the apps trade with each other using cpu/memory as money lol and they earn money by usage

No. No. No.

Microsoft need to update the spec for all new personal computers to include mandatory pre-load hardware. This would have a secondary CPU, RAM and storage used for pre-loading licensed Office products before your laptop boots. AI would analyse your usage patterns and fire-up Office for you before you even get to work in the morning.

Perhaps, this could even allow you to have Office on-hand, ready-to-use on its own hardware module, while you develop Linux application on your main CPU.

Further down the line. Someone see an opportunity to provide access to compatible modules in the cloud, allowing re-use of older incompatible hardware. But there would be the danger that service (without the support of MS), may go bust, leaving those users without their mandatory instant access to licensed Office products, forcing upgrades to even newer hardware.