Read more of this story at Slashdot.
Read more of this story at Slashdot.
Windows 11 is testing a new underlying improvement for File Explorer that could potentially reduce RAM usage when you’re actively searching for an image or other files, such as those in Excel or PowerPoint. Microsoft is optimizing “search” performance in File Explorer, as it’s been causing high memory usage.
Microsoft is testing an efficient File Explorer search bar in Windows 11 Build 26220.7523 or newer, but it’s currently locked to Windows Insider machines only. Once you’ve access to the feature, File Explorer will automatically remove duplicate file indexing operations, which means Windows will do less redundant work when you search in File Explorer.
“Made some improvements to File Explorer search performance by eliminating duplicate file indexing operations, which should result in faster searches and reduced system resource usage during file operations.”
File Explorer Search is not a separate index or engine, as it’s built on top of Windows Search Indexer. While indexer is designed to be ‘smart,’ duplicate file indexing operations can happen sometimes, and in those cases, Windows ends up scanning or processing the same files or folders more than once for indexing purposes.
Windows Search index will now avoid duplicate file operations, which should result in less disk I/O, lower CPU cycles, and fewer background indexing tasks, so it’ll automatically reduce RAM usage.

Microsoft is also making other parts of File Explorer better, including the context menu, which has been the center of attention lately because of the clutter mess it has become over the past few years.
In our tests, Windows Latest observed that Microsoft is moving options like “Compress to,” “Copy as path,” “Rotate right,” “Rotate left,” and “Set as desktop background” to a separate sub-menu called “Manage file.” On another PC, this sub-menu is called “Other actions,” which seems to suggest that Microsoft wants to dump all lesser-used options in this sub-menu.
Alll these improvements are being tested and will be rolled out in the last week of January or February.
The post Microsoft says Windows 11 File Explorer will soon use less RAM when you search files appeared first on Windows Latest
In this BONUS episode, we explore the organizational barriers that prevent companies from becoming truly software-native. Despite having proof that agile, iterative approaches work at scale—from Spotify to Amazon to Etsy—most organizations still struggle to adopt these practices. We reveal the root cause behind this resistance and expose four critical barriers that form what we call "The Organizational Immune System." This isn't about resistance to change; it's about embedded structures, incentives, and mental models that actively reject beneficial transformation.
"Project management as a mental model is fundamentally incompatible with software development. And will continue to be, because 'project management' as an art needs to support industries that are not software-native."
The fundamental problem isn't about tools or practices—it's about how we think about work itself. Project management operates on assumptions that simply don't hold true for software development. It assumes you can know the scope upfront, plan everything in advance, and execute according to that plan. But software is fundamentally different. A significant portion of the work only becomes visible once you start building. You discover that the "simple" feature requires refactoring three other systems. You learn that users actually need something different than what they asked for. This isn't poor planning—it's the nature of software. Project management treats discovery as failure ("we missed requirements"), while software-native thinking treats discovery as progress ("we learned something critical"). As Vasco points out in his NoEstimates work, what project management calls "scope creep" should really be labeled "value discovery" in software—because we're discovering more value to add.
"Software hypotheses need to be tested in hours or days, not weeks, and certainly not months. You can't wait until the end of a 12-month project to find out your core assumption was wrong."
The timing mismatch between project management and software development creates fundamental problems. Project management optimizes for plan execution with feedback loops that are months or years long, with clear distinctions between teams doing requirements, design, building, and testing. But software needs to probe and validate assumptions in hours or days. Questions like "Will users actually use this feature?" or "Does this architecture handle the load?" can't wait for the end of a 12-month project. When we finally discover our core assumption was wrong, we need to fully replan—not just "change the plan." Software-native organizations optimize for learning speed, while project management optimizes for plan adherence. These are opposing and mutually exclusive definitions of success.
"When you force software into project management language, you lose the ability to manage what actually matters. You end up tracking task completion while missing that you're building the wrong thing."
The vocabulary we use shapes how we think about problems and solutions. Project management talks about tasks, milestones, percent complete, resource allocation, and critical path. Software needs to talk about user value, technical debt, architectural runway, learning velocity, deployment frequency, and lead time. These aren't just different words—they represent fundamentally different ways of thinking about work. When organizations force software teams to speak in project management terms, they lose the ability to discuss and manage what actually creates value in software development.
"Agile software development represents the first worldwide trend in scholarship around software delivery. But most organizational investment still goes into project management scholarship and training."
There's extensive scholarship in IT, but almost none about delivery processes until recently. The agile movement represents the first major wave of people studying what actually works for building software, rather than adapting thinking from manufacturing or construction. Yet most organizational investment continues to flow into project management certifications like PMI and Prince2, and traditional MBA programs—all teaching an approach with fundamental problems when applied to software. This creates an industry-wide challenge: when CFOs, executives, and business partners all think in project management terms, they literally cannot understand why software needs to work differently. The mental model mismatch isn't just a team problem—it's affecting everyone in the organization and the broader industry.
"You commit to a scope at the start, when you know the least about what you need to build. The budget runs out exactly when you're starting to understand what users actually need."
Project thinking drives project funding: organizations approve a fixed budget (say $2M over 9 months) to deliver specific features. This seems rational and gives finance predictability, but it's completely misaligned with how software creates value. Teams commit to scope when they know the least about what needs building. The budget expires just when they're starting to understand what users actually need. When the "project" ends, the team disbands, taking all their accumulated knowledge with them. Next year, the cycle starts over with a new project, new team, and zero retained context. Meanwhile, the software itself needs continuous evolution, but the funding structure treats it as a series of temporary initiatives with hard stops.
"Instead of approving $2M for 9 months, approve smaller increments—maybe $200K for 6 weeks. Then decide whether to continue based on what you've learned."
Software-native organizations fund teams working on products, not projects. This means incremental funding decisions based on learning rather than upfront commitments. Instead of detailed estimates that pretend to predict the future, they use lightweight signals from the NoEstimates approach to detect problems early: Are we delivering value regularly? Are we learning? Are users responding positively? These signals provide more useful information than any Gantt chart. Portfolio managers shift from being "task police" asking "are you on schedule?" to investment curators asking "are we seeing the value we expected? Should we invest more, pivot, or stop?" This mirrors how venture capital works—and software is inherently more like VC than construction. Amazon exemplifies this approach, giving teams continuous funding as long as they're delivering value and learning, with no arbitrary end date to the investment.
"'The business' doesn't understand software—and often doesn't want to. They think in terms of features and deadlines, not capabilities and evolution."
Project thinking reinforces organizational separation: "the business" defines requirements, "IT" implements them, and project managers coordinate the handoff. This seems logical with clear specialization and defined responsibilities. But it creates a disaster. The business writes requirements documents without understanding what's technically possible or what users actually need. IT receives them, estimates, and builds—but the requirements are usually wrong. By the time IT delivers, the business need has changed, or the software works but doesn't solve the real problem. Sometimes worst of all, it works exactly as specified but nobody wants it. This isn't a communication problem—it's a structural problem created by project thinking.
"Instead of 'build a new reporting dashboard,' the goal is 'reduce time finance team spends preparing monthly reports from 40 hours to 4 hours.'"
Software-native organizations eliminate the business/IT separation by creating product teams focused on outcomes. Using approaches like Impact Mapping, they start with behavior change instead of features. The goal becomes a measurable change in business behavior or performance, not a list of requirements. Teams measure business outcomes, not task completion—tracking whether finance actually spends less time on reports. If the first version doesn't achieve that outcome, they iterate. The "requirement" isn't sacred; the outcome is. "Business" and "IT" collaborate on goals rather than handing off requirements. They're on the same team, working toward the same measurable outcome with no walls to throw things over. Spotify's squad model popularized this approach, with each squad including product managers, designers, and engineers all focused on the same part of the product, all owning the outcome together.
"Here's the real risk in software: delivering software that nobody wants, and having to maintain it forever."
Project thinking creates elaborate risk management processes—steering committees, gate reviews, sign-offs, extensive documentation, and governance frameworks. These create the appearance of managing risk and make everyone feel professional and in control. But paradoxically, the very practices meant to manage risk end up increasing the risk of catastrophic failure. This mirrors Chesterton's Fence paradox. The real risk in software isn't about following the plan—it's delivering software nobody wants and having to maintain it forever. Every line of code becomes a maintenance burden. If it's not delivering value, you're paying the cost forever or paying additional cost to remove it later. Traditional risk management theater doesn't protect against this at all. Gates and approvals just slow you down without validating whether users will actually use what you're building or whether the software creates business value.
"Software-native organizations don't see 'governance' and 'agility' as a tradeoff. Agility IS governance. Fast learning loops ARE how you manage risk."
Software-native organizations recognize that agile and product thinking ARE risk management. The fastest way to reduce risk is delivering quickly—getting software in front of real users in production with real data solving real problems, not in demos or staging environments. Teams validate expected value by measuring whether software achieves intended outcomes. Did finance really reduce their reporting time? Did users actually engage with the feature? When something isn't working, teams change it quickly. When it is working, they double down. Either way, they're managing risk through rapid learning. Eric Ries's Lean Startup methodology isn't just for startups—it's fundamentally a software-native management practice. Build-Measure-Learn isn't a nice-to-have; it's how you avoid the catastrophic risk of building the wrong thing.
"Which approach actually manages risk? The second one validates assumptions quickly and cheaply. The first one maximizes your exposure to building the wrong thing."
The contrast between approaches is stark. Risk management theater involves six months of requirements gathering and design, multiple approval gates that claim to prevent risk but actually accumulate it, comprehensive test plans, and a big-bang launch after 12 months. Teams then discover users don't want it—and now they're maintaining unwanted software forever. The agile risk management approach takes two weeks to build a minimal viable feature, ships to a subset of users, measures actual behavior, learns it's not quite right, iterates in another two weeks, validates value before scaling, and only maintains software that's proven valuable. The second approach validates assumptions quickly and cheaply. The first maximizes exposure to building the wrong thing.
"When you try to 'implement agile' without addressing these structural barriers, the organization's immune system rejects it. Teams might adopt standups and sprints, but nothing fundamental changes."
These barriers work together as an immune system defending the status quo. It starts with the project management mindset—the fundamental belief that software is like construction, that we can plan it all upfront, that "done" is a meaningful state. That mindset creates funding models that allocate budgets to temporary projects instead of continuous products, organizational structures that separate "business" from "IT" and treat software as a cost center, and risk management theater that optimizes for appearing in control rather than actually learning. Each barrier reinforces the others. The funding model makes it hard to keep stable product teams. The business/IT separation makes it hard to validate value quickly. The risk theater slows down learning loops. The whole system resists change—even beneficial change—because each part depends on the others. This is why so many "agile transformations" fail: they treat the symptoms (team practices) without addressing the disease (organizational structures built on project thinking).
"Once you see the system clearly, you can transform it. You now know the root cause, how it manifests, and what the alternatives look like."
Understanding these barriers is empowering. It's not that people are stupid or resistant to change—organizations have structural barriers built on a fundamental mental model mismatch. But once you see the system clearly, transformation becomes possible. You now understand the root cause (project management mindset), how it manifests in your organization (funding models, business/IT separation, risk theater), and what the alternatives look like through real examples from companies successfully operating as software-native organizations. The path forward requires addressing the disease, not just the symptoms—transforming the fundamental structures and mental models that shape how your organization approaches software.
About Vasco Duarte
Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.
You can link with Vasco Duarte on LinkedIn.
1145. In this bonus segment from October, I talk with Ben Zimmer about "hella" and how even yearbook messages can be digitized to help preserve the language record. Ben shares the full story of this slang term, and we also talk about the detective work that led to the OED using Run DMC's use of "drop" in “Spin Magazine” as a citation.
Ben Zimmer's website: Benzimmer.com
Ben Zimmer's social media: Bluesky. Facebook.
Links to Get One Month Free of the Grammar Girl Patreon (different links for different levels)
🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)
🔗 Watch my LinkedIn Learning writing courses.
🔗 Subscribe to the newsletter.
🔗 Take our advertising survey.
🔗 Get the edited transcript.
🔗 Get Grammar Girl books.
🔗 Join Grammarpalooza. Get ad-free and bonus episodes at Apple Podcasts or Subtext. Learn more about the difference.
| HOST: Mignon Fogarty
| Grammar Girl is part of the Quick and Dirty Tips podcast network.
| Theme music by Catherine Rannus.
| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
Welcome to episode 335 of The Cloud Pod, where the forecast is always cloudy! This pre-Christmas week, Ryan and Justin have hit the studio to bring you the final show of 2025. We’ve got lots of AI images, EKS Network Policies, Gemini 3, and even some Disney drama.
Let’s get into it!
01:06 Meta’s multibillion-dollar AI strategy overhaul creates culture clash:
02:23 Ryan – “I guess I really don’t understand the business of the AI models. I guess if you’re going to offer a chat service, you have to have a proprietary model, but it’s kind of strange.”
03:04 Disney says Google AI infringes copyright “on a massive scale” – Ars Technica
04:06 Ryan – “Disney – suing for copyright infringement – shocking.”
04:54 Disney invests $1 billion in OpenAI, licenses 200 characters for AI video app Sora – Ars Technica
06:26 Ryan – “Is it just a way to get out of the lawsuit so they can generate the content?”
07:12 The new ChatGPT Images is here | OpenAI
07:38 Justin – “It’s very competitive against Nano Banana, and I was looking at some of the charts, and it’s already jumped to the top of the charts.”
08:52 Introducing GPT-5.2 | OpenAI
10:06 Ryan – “I’m happy to see the improved safety features because that’s come up in the news recently and had some high-profile events happen, where it’s become a concern, for sure. So I want to see more protection in that space from all the providers.”
10:58 Cedar Joins CNCF as a Sandbox Project | AWS Open Source Blog
12:05 Ryan – “I think this kind of policy is going to be absolutely key to managing permissions going forward.”
12:50 GuardDuty Extended Threat Detection uncovers a cryptomining campaign on Amazon EC2 and Amazon ECS | AWS Security Blog
55:31 Justin – “Hackers have the same tools we do for development.”
16:17 Amazon EKS introduces enhanced network policy capabilities | Containers
17:30 Ryan – “This is one of those things that’s showing a maturity level of container-driven applications. It’s been a while since security teams have been aware of some of the things you can do with network policies and routing, and so you want to empower your developers, but also being able to have a comprehensive way to ban and approve has been missing from a lot of these ingress controllers. So this is a great thing for security teams, and probably terrible for developers.”
19:12 Automate java performance troubleshooting with AI-Powered thread dump analysis on Amazon ECS and EKS | Containers
20:55 Justin – “This tells me that if you have a bad container that crashes a lot, you could spend a lot of money on LLM usage for tokens analyzing your exact same crash dump every time. Do keep that in mind.”
22:50 EC2 Auto Scaling now offers a synchronous API to launch instances inside an Auto Scaling group
23:47 Ryan – “I find that the things that it’s allowing you to tune – it’s the things that I moved to autoscaling for; I don’t want to deal with any of this nonsense. And so you still have to maintain your own orchestration, which understands which zone that you need to roll out to, because it’s going to have to call that API.”
24:28 Announcing cost allocation using users’ attributes
25:26 Justin – “There’s lots of use cases; this gets interesting real quickly. It’s a really nice feature that I’m really happy about.”
26:34 Introducing Gemini 3 Flash: Benchmarks, global availability
27:01 Justin – “This, just in general, is a pretty big improvement from not only the cost perspective, but also the overall performance, and the ability to run this on local devices, for like Android phones, is gonna be a huge breakthrough in LM performance on the device. So I suspect you’ll see a lot of Gemini 3 flash getting rolled out all over the place because it does a lot of things really darn well.”
28:16 Connect Google Antigravity IDE to Google’s Data Cloud services | Google Cloud Blog
29:15 Announcing official MCP support for Google services | Google Cloud Blog
30:34 MCP support for Apigee | Google Cloud Blog
31:07 Ryan – “I just did some real-time analysis about the features of the MCP and then also the browser and stuff. It’s one of those things where it is the newer model of coding, where you’re having distributed agents do tasks, and that, so the new IDs are taking advantage of that… And it is a VS Code fork. So it’s very comfortable to your VS Code users.”
32:05 Application Design Center now GA | Google Cloud Blog
33:10 Ryan – “It’s kind of the pangea that everyone’s been hoping for, for a long time. With AI making it possible. Being able to plain text speak your infrastructure into existence…I definitely like this model better than like Beanstalk or the hosted application model, which has been the solution until this. This is the answer I want.”
34:30 Microsoft will finally kill obsolete cipher that has wreaked decades of havoc – Ars Technica
36:06 Ryan – “It’s so complex, everyone just accepts the defaults just to get it up and going, and if you don’t know how compromised the cipher is, you don’t really prioritize getting back and fixing the encryption. So I’m really happy to see this; it’s always been a black mark that’s made me not trust Windows.”
37:11 Azure Storage innovations: Unlocking the future of data
38:26 Ryan – “It just dawned on me, as you’re reading through here… this is interesting; getting all this high performance from object stores just sort of blows my mind. And then I realized that all these sorts of ‘cloud file systems’ have been backed underneath by these object stores for a long time; like, of course, they need this.”
39:49 Future-Ready Cloud: Microsoft’s U.S. Infrastructure Investments
40:33 Ryan – “AI is definitely driving a lot of this, but like with large data sets, you don’t really want that distributed globally. But I also think that they’re just purely running out of space.”
41:17 Azure Networking Updates: Secure, Scalable, and AI-Optimized
42:45 Ryan – “If you have those high-end network throughput needs, that’s fantastic! It’s been a while since I’ve really got into cloud at that deep layer, but I do remember in AWS the VPN limitations really biting; it was easy to hit those limits really fast.”
44:22 Roomba maker iRobot swept into bankruptcy
And that is the week in the cloud! Visit our website, the home of the Cloud Pod, where you can join our newsletter, Slack team, send feedback, or ask questions at theCloudPod.net or tweet at us with the hashtag #theCloudPod