Showing posts with label Visual Studio. Show all posts
Showing posts with label Visual Studio. Show all posts

Wednesday, July 29, 2026

Microsoft forces AI on developers

Microsoft, in a recent update to its Visual Studio IDE, has forced Copilot AI onto developers. It's not an obvious change, in fact, it affects a rarely-used corner of the IDE: the profiler.

A profiler is a useful if not often used tool. Most of the time a programmer is editing the code. Somewhat less time is spent compiling and linking the source code into executable files. Depending on the developer and the quality of the code (which may have been written by others) some amount of time is spent debugging the code - running the code in 'slow motion' and observing which lines are executed and which are not.

The profiler is a tool to measure the code, specifically as it runs. Different profilers (or different parts of a large profiler) measure the time to execute functions (to identify which functions are slow), the amount of memory used, file operations, and "code coverage" (to identify code that is not tested).

Microsoft's Visual Studio has a profiler built as one of its tools. (And it's a nice, capable profiler.)

But Microsoft's latest version of Visual Studio adds Copilot to the profiler, and adds it in such a way that you cannot use the profiler without using Copilot. (You don't seem to have to pay for this specific use of Copilot, though.)

It so happens that a client has decided to disable Copilot in their organization. (Exactly how is not important.) They have their reasons to do so, and while I may not agree with their reasons I do agree with their goal of disabling Copilot. (I think Copilot and the other programming AIs are not quite ready for prime time.)

Working in this environment it is obvious that the new version of Visual Studio is dependent on Copilot: the profiler refuses to run. (It's not quite obvious; it took a few seasoned hands to identify the connection.)

A few observations about this change:

First, Microsoft, rather than allowing developers to enable Copilot, is forcing Copilot upon them. That's not going to win them many friends. Selling a new feature ("See this new feature! It's shiny!") tends to keep people on your team. Forcing a change makes people angry -- possibly angry enough to leave your team.

Second, Microsoft has built a new profiler that requires Copilot and cannot work without it. This is a poor design choice. Good design of systems allows components to work even when parts of them are not available. (And as the profiler worked just fine without Copilot two weeks ago, I don't see how Copilot is such a necessary part of the profiler.)

Third, if Microsoft is willing to force Copilot onto developers for the profiling tool, they may be planning to force Copilot onto developers for other parts of Visual Studio. Auto-completion, for example. Or syntax coloring. Or debugging. Or maybe even code optimization by the compiler. I'm not sure Copilot is ready for such tasks.

Fourth, if Microsoft is willing to force Copilot onto developers, they may be planning to force Copilot onto other users -- in Microsoft tools such a as Word, Excel, Powerpoint, Access, and maybe even things like Maps. (I'm not talking about making Copilot available to these tools; I'm suggesting that Microsoft make Copilot mandatory in these tools.)

The bundling of Copilot into the Visual Studio profiler is a small change for a small audience. I don't see people in significant numbers moving away from Microsoft because of it. A few might, but nothing significant.

But it doesn't increase the appeal of Visual Studio. Developers like control over their tools. I don't see people joining Microsoft's team because they are forced to use Copilot.

One could interpret this change (for Visual Studio) as an experiment: Will users work with Copilot? Or as an act of desperation: We need to get higher usage numbers for Copilot. In either case, it's an internal issue. Microsoft is not boosting its appeal to developers, and not setting a higher standard for its competitors to meet. As an internal issue, the rating of success (or failure) will be determined by internal numbers. I don't expect we'll see more about this change.


Tuesday, February 12, 2019

Praise for Microsoft

I am not Microsoft's biggest fan. I disliked their products and strategies in the 1990s, when they had a virtual monopoly on desktop operating systems, office software, and development tools. Yet I must give them credit for two recent products: OneDrive and Visual Studio Code.

OneDrive

OneDrive synchronizes files across multiple devices. I can store a file in OneDrive on computer A and later retrieve it on computer B. OneDrive stores data on Microsoft's servers and associates it with my account. If I log in to a Windows computer with my ID and password, I can see all of my files on OneDrive. The files are not copied to the local computer, they are simply available for me to view, change, or delete.

OneDrive also provides storage for online services such as Office Online. This lets me use any computer, even a public one in a library. (I think. I have yet to try this. But it makes sense for Microsoft to do things this way.)

Visual Studio Code

The other product that deserves credit is Visual Studio Code.

Microsoft advertises Visual Studio Code as an editor, yet it is much more. It edits, color-highlights, checks syntax, refactors, debugs (at least with Python), and integrates with git. It has an impressive array of features in a small package. What is significant is that the features are just the right set -- at least for me, and I suspect a large number of developers. It is not weighed down with all of the features of Microsoft's classic Visual Studio package. Visual Studio Code omits the templates and the auto-generation. It replaces the package manager with a series of lightweight plug-ins. It seems to ignore Team Foundation Server (and services), although I could be mistaken about that. (Perhaps there is an enterprise version of VS Code that connects to TFS.)

Beyond the feature set, Visual Studio Code... works. It's a competent product, one that feels good to use. It has just enough to get the job done, and it gets the job done well. I feel comfortable using it. (And that's a rare thing with me and Microsoft products.)

Visual Studio Code is a departure from the traditional Microsoft approach to software. The old Microsoft built software for Windows -- and Windows only. (A few exceptions were made for Mac OS.) Visual Studio Code breaks from that tradition: it is available for Windows, Mac OS, and Linux. This is indeed a ground-breaking project.

OneDrive and Visual Studio Code make for a pleasant experience when developing code. Microsoft deserves credit for bold choices and good tools. If you have not tried them, I recommend that you do.

What have you got to lose?

Tuesday, March 31, 2015

Our tools shape our languages, and our programs

Our applications are shaped by many forces: budget, available talent, time, languages, and tools.

When designing applications, languages are sometimes overlooked. Yet it should be obvious to anyone who has used multiple languages. Different languages have different capabilities. C and its descendants have the notions of pointers, something absent in COBOL, Fortran, and BASIC. The notion of pointers lets one build dynamic, complex data structures; such structures are not possible in pointerless languages.

Our tools have an effect on our languages, which can have an effect on our applications.

In the Microsoft world, C# is a simple language, yet the .NET framework of classes is complex and wordy. A simple application in C# requires a significant amount of typing, and a moderately complex application requires a large amount of typing.

Languages such as Perl, Python, and Ruby require less typing. How is it that the .NET framework is so complex? The answer, I believe is in Visual Studio.

Microsoft's development environment is the result of competition and years (decades?) of development. Over that time, Microsoft has added features: debugging, test case management, design documents, and editing features. One significant editing feature is the auto-completion of typing with context-sensitive information. When I am typing a C# program and I start typing a name of a variable, Visual Studio gives me a list of existing variable names. (It also knows that the declaration of a variable is different from the use of a variable, and does not prompt me with existing names.) Visual Studio also lists methods for objects and provides templates for parameters.

This assistance from Visual Studio reduces the burden of typing. Thus, applications that use the .NET framework can appear wordy, but the effort to create them is less than it appears. (Some have argued that the assistance from Visual Studio helps reduce errors, as it suggests only valid possibilities.)

Thus, a development tool can affect our languages (and class frameworks), which in turn can affect our applications. When choosing our tools, we should be aware of their properties and how they can affect our projects.

Thursday, May 24, 2012

Microsoft Visual Studio Express abandons the desktop

Visual Studio 2011 Express Edition (the free version) does not support desktop applications.

By abandoning the desktop for entry-level users, Microsoft is sending a clear message: the Windows desktop is now a mature market. By "mature", Microsoft is limiting development of desktop applications to professionals -- people who are willing to pay for the tools. The hobbyists are "guided" into the web and Metro environments.

As I see it, Microsoft recognizes different futures for desktop and web/Metro applications. Web apps and Metro apps have a vibrant future with lots of growth and creativity. Desktop apps... don't. Desktop apps are maintained, but not enhanced.

This is not to say that desktop apps will go away. There are too many businesses with too many critical applications that run on the desktop.

But it does confirm a shift in the landscape. New apps will be mobile (iPhone/Android/Metro) apps. Or web apps, for those organizations that do not want to move to mobile.

Just as mainframe applications are still with us (billing systems, payroll, general ledger...) Windows desktop applications will remain with us. But the environment is now sterile. It bears no fruit.

Microsoft's choice with its latest offering of Visual Studio is the right one. Hobbyists and beginners must work in fertile environments.