3 ms·
Team X is responsible for feature Foo; feature Foo is slow; team X introduces Foo-preload, metrics go up, person responsible gets a bonus. Multiply that by ten
by kilotaras 1y ago
Team X is responsible for feature Foo; feature Foo is slow; team X introduces Foo-preload, metrics go up, person responsible gets a bonus.
Multiply that by tens (or even hundreds) of teams and your app startup (either on desktop or mobile) is now a bloated mess. Happened to Office, Facebook iOS and countless others.
One solution is to treat startup cycles as a resource similar to e.g. size or backend servers.
- threatripper 1y agoThe solution is simple: New OKRs and KPIs in the next cycle reversing some of the current ones, then new bonuses for reaching them. Repeat.
- taneq 1y ago“I could do this all day!”
- HPsquared 1y agoThen 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.
- macleginn 1y agoThe only impact values I see on my home machine are "Not measured" and "None".
- vasco 1y agoOffice codebase is soon going to probably be older than most people that work on it.
- andruby 1y agoThat 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".
- claudex 1y agoOffice was released in 1990, but Excel in 1985 and Word in 1983.
- bcraven 1y ago"but claude.ai guesses" To my ears this is the equivalent of "some guy down the pub said", but maybe I am a luddite.
- n8m8 1y agoYou're not a luddite, they disclosed it because you're _supposed_ to take it with a grain of salt
- gigel82 1y agoI'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.
- immibis 1y agoRaymond Chen wrote about this.
- bjackman 1y ago> 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.
- netruk44 1y agoAs 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™).
- bjackman 1y agoMakes 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_what_it_does https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_w... [2] https://www.astralcodexten.com/p/highlights-from-the-comments-on-posiwid https://www.astralcodexten.com/p/highlights-from-the-comment...
- alliao 1y agomake the apps trade with each other using cpu/memory as money lol and they earn money by usage
- RegW 1y agoNo. 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.