in Windows, some teams/people use it others don't. Historically it hasn't worked well with some of the internal build/test/etc stuff, that's mostly changed in recent years.
161 karma · joined December 11, 2011
(I have no idea what will happen. 内卷 or intelligence explosion both seem plausible.)
tbh all of this has always struck me as an ego thing from the MAI team, who are mostly based in Silicon Valley, not Redmond, and think of themselves as too cool for Microsoft
† btw, what became Windows 11 started development as just another Windows 10 feature update, and what gets branded as a "new release" vs an "update" is mostly a marketing decision.
Note that if other browsers themselves adopt new Windows APIs in competitive response, that actually still benefits Microsoft because ultimately they don't care about the browser for its own sake, they care about increasing Windows API and feature usage across all browsers. But in practice competing browsers tend to be late adopters of new Windows stuff (e.g., even now nothing but IE supports DComp/DManip and Chrome is just very recently getting around to improving its Windows high-DPI and text rendering support), hence Microsoft funds IE.
1) there's overhead associated with coming up with a hierarchical file structure, keeping it updated whenever your problems or your understanding of them change, etc.
2) there's overhead associated with always remembering to put a file in the "right" place every time you save it, actually navigating there to save it, and then fishing it out of the "right" place every time you need a file (getting to a file with search can sometimes be faster than navigating to it even if you know exactly where it is)
3) there is no perfect hierarchical structure for information; there will always be situations where x/y makes as much sense as y/x and both are sometimes inconvenient
this is not to suggest that search, tags and other alternative mechanisms don't have their own problems.
some development efforts are just really hard to scale out.
basically the idea is to split the SDET role into two - SE testing (closer to the code than SDETs used to be) and "quality" (further from the code than SDETs used to be). SDET testing, though not directly driven by the code structure, tended to be at a pretty low level driven by a detailed functional spec.