The Future of Visual Studio: Interactive Expert Panel | When Does Visual Studio Deprecate a Feature?

Duration: 6:19 1203 transcript words EN summary

Video summary

The discussion centers on the delicate balance between modernizing Visual Studio by removing deprecated features and maintaining long-term compatibility for existing codebases. The panelists emphasize that while deprecation can be a painful process, it is driven by a primary motivation to ensure customer success rather than simply cutting legacy code. A key argument presented is that Visual Studio, much like the Windows operating system, has successfully maintained backward compatibility for decades, allowing applications written years ago to still run today. However, this commitment to supporting old technologies creates challenges, as maintaining a vast public API surface area and supporting outdated frameworks like COM or MFC can slow down progress on new workflows and increase the product's size. To address these issues, the team has become more willing to remove features that are no longer leveraged by the majority of users, utilizing telemetry data to identify low-usage components. A common strategy mentioned is the "scream test," where a feature is effectively turned off or hidden to see if any critical users complain; if significant feedback arises, the team engages in conversation to understand the necessity of that feature before making final decisions. This approach acknowledges that while many modern developers may not use legacy tools like MFC or IIS, large enterprises often remain dependent on them, making it difficult for Microsoft to simply declare such features obsolete without considering the specific needs of their diverse customer base. In terms of implementation, the focus has shifted toward better componentization and customizable installations rather than moving deprecated features into separate products or open-source projects. The panelists note that while they have occasionally released components as open source, they generally prefer to keep features within Visual Studio, perhaps making them optional by default instead of removing them entirely. This allows users to tailor their installation to only include the workloads they actually need, such as avoiding unnecessary C++ components for C# developers, which reduces update payloads and improves performance. Ultimately, the conclusion is that while removing unused features is desirable for a lighter, faster product, the reality of user dependency means that even deprecated items often remain in the ecosystem longer than ideal, requiring careful evaluation of community interest and investment before any removal occurs.

Read the full video transcript

So, the other half of that question was about deprecation. Are there any ideas of taking like something that's old and not used very much, maybe some larger chunks, and taking that out of Visual Studio? Maybe it would speed things up or create a smaller install or faster install time or something like that. >> Yeah, deprecation is fun in a product like Visual Studio. Uh and by fun, I mean painful. Uh really painful. Uh you know, and it's it's one of those challenges because it's one of those things where I mean, we're primarily motivated by making sure that you all are as successful as you can be, right? And so, we have to weigh this like, well, I I personally believe strongly that one of the reasons that Windows was so successful and continues to be successful is that you can like, I can still run applications I wrote in high school, right? On Windows today, and that is staggering, right? Um both because my code actually works, which is staggering in and of itself, and that the compatibility has been maintained for so long. And that is an incredibly difficult thing for Windows. Um Visual Studio is similar. You can run extensions that were written, you know, decades ago, right? And and they still work. And in some ways that sucks for the team, right? Because maintaining that public surface area, uh you know, you you get uh shoot you know, like blocked in a corner, right? You're like, well, you know, when we started, COM was like the primary thing, and like that is great, right? Except that, you know, a lot of people don't think about COM very much anymore, right? Uh and async wasn't really a thing, right? Uh I mean, there's just like the CPUs and the memory and all the things, right? Um So, So, I've explained why it's hard. Uh that said, I think that we are more open to removing things that are slowing down the progress for adding features that adapt better to the new workflows, right? And so, if there things that people basically aren't leveraging needing anymore, then we're we're much more willing to remove those than we previously were. Um Now, it just becomes a question of identifying those things. So, one of the ways that we identify them is primarily through telemetry, like usage, right? Like, we'll see people are using One of the tricks with that is that, you know, for large some large enterprises, they'll turn off telemetry, right? And so, then we end up in this position where we're like, well, we we know like we've even like see there's only like 11 people that are using this feature. Let's take it out, right? And then we'll remove it, and then, you know, well, some large enterprise will be like, "Hey, that is a critical feature for us." So, um so, anyway, it's kind of a We usually do what we call a scream test, which I'm sure you all have done before, where we'll like turn it off and we'll listen to see if anybody screams, right? And if they do, then, you know, then then we'll have a conversation with them. Um Yeah. >> I just double down on that. Like, turns out we really are motivated by like your success. And while lots of VS might feel like, "Hey, this is legacy or this is something I'd never do." Like, "I've never used MFC, etc." So many customers are still dependent upon that. Like, you know, you were just talking about how hard it is to update Visual Studio. Part of that's because we interact with the OS. I did Soul and update IIS. So, if you're a modern developer, you're not using IIS, you're using Kestrel or something like that. But, we have so many customers that do. And so, it's very difficult for us to make those, you know, say, "No, you can't use this part anymore." because realistically that is the product they need and the product they're using. But, there are things you can do. Like, things we've been doing more recently is trying to better split out some of the componentization. So, for example, one of the classic problems is we have a lot of customers who will install both C# and the C++ workloads and never use a C++ workload, but they've installed it. So, every time C++ needed to push down a restart, which we really worked hard on to mitigate, but you'd get those updates, you'd get that payload, and things like that, and send us a telemetry signal that you were using it. Um so, like definitely, like especially in enterprises where perhaps you have offline layouts and the enterprise admin has just done slash all and literally getting every single component, the more you can you customize your own installation to match your repo and deterministically through VS config and other ways specify what you need, that also helps in the longer term because your components you have that you depend upon can be known and perhaps then we don't need to install the other things, or you don't need to install them, and so they won't be loaded. >> I will say one more thing, which is that you you know, you you mentioned like oh, would would we potentially pull those out into, you know, some other, you know, product or shell or something, and then that thing people could still use, right? But it would no longer, you know, be you know, potentially slowing down Visual Studio or whatever, right? Um we haven't done that very much. Um the way or rather the mechanisms that we've used to do that kind of thing has traditionally been more like we'll put that thing up as an open source, but we don't like ship a product or it is like well, okay, the community will do it. I don't know that we'll change that. Um it would sup- it would surprise me. It's probably either going to be the case that we keep it in Visual Studio. Maybe maybe it'll become off by default, right? Um or if we thought that there was still some usage, but we knew we weren't investing when we knew the community cared and wanted to take it forward, we would look more at something like oh, would that be something that makes more sense as an OSS project? >> And just just to add to the whole deprecation, um it was not more than like I think May or June someone was asking me about like what happened to VB6 support. So, I think they had to they left Visual Studio for some while some time and they came back to Visual Studio a newer version and had to maintain an old VB6 internal app. And yeah, we we ripped that out like 12 years ago or something. And they had to go find like a Visual Studio 2015 or when maybe even earlier. Um but so, even if you deprecate something that isn't used, someone still uses it. So, it is hard.