In-Depth
Sneak Peek at the Future of Visual Studio .NET
S. "Soma" Somasegar, corporate vice president of the Developer Division at Microsoft, speaks to VSM about the future of Visual Studio, including the lifecycle-management tools.
<>
S.“Soma” Somasegar, corporate vice president of the Developer Division at Microsoft and VSLive! Orlando keynote speaker, talks to VSM Editor in Chief Patrick Meader about the future of Visual Studio, including Microsoft’s new Express product lines and its lifecycle-management tools. Also discussed: global outsourcing, .NET adoption among VB5/6 users, and Microsoft’s progress on security.
Somasegar is primarily responsible for all the developer-related languages, tools, and platforms within Microsoft, including Visual Studio, Web Platform and Tools, .NET Framework, Common Language Runtime, and other .NET Developer Platform technologies. He also oversees the India Development Center in Hyderabad, India.
PM: You came to your position after 15 years in the Windows division. How do the Windows and Developer divisions fit together?
SS: The two divisions go hand-in-hand together. We are a platform company at heart. For our platform to be successful, we need rich support from developer tools. We need to give developers of the world a reason to take a bet on writing applications for the platform. So, from day one, we’ve been concentrating on what we can do to court developers from a platform and tools perspective. Coming from the Windows side, I want to ensure the tightest integration possible between the tools and the platform, which will translate to a better and far easier developer experience.
PM: Microsoft seems to be taking a fundamentally different approach with Visual Studio 2005. In the past, what defined the various versions of your development tools was how much stuff you included in the box. The Enterprise Edition got all of the goodies, and each succeeding box down the chain included fewer goodies. This time, though, you appear to be targeting specific users for the Team/Enterprise and Express editions, and to have tailored your offerings around their needs, rather than simply including less and less in different boxes down the chain. Tell me what distinguishes Microsoft’s approach on its Team System product from its Express versions.
SS: One decision we made early in the creation of Visual Studio 2005 was to move away from the idea that one size fits all, that one tool fits all developer needs. Our goal was to create the right product, for the right customer, at the right price point.
Broadly speaking, I’d assert that Visual Studio 2005 is about providing a great toolset for developers. But who exactly is a developer? A 14-year old who wants to get started with programming? You could call this person a developer. The person who says, “This weekend, I’m going to create a DVD cataloguing application so I can track my DVDs better?” You could call this person a developer, too. The person who is sitting in a cubicle writing application customization software? You can call this person a developer, too. The person who has a career building internal process and collaboration software? This person is a developer, too. The person who works for an enterprise company building a line-of-business application? Of course, he’s a developer, too.
All these people are developers, but there is a wide range of what they need and expect from their development tools. We sat down and asked ourselves how we could break their needs down more specifically and deliver tools that catered to their particular needs and requirements. We wanted to create the right tools for the right people, which is fundamentally different than simply including the subset of tools from a larger group of tools that will let them accomplish a particular task.
We looked at the hobbyist and academic developers, and asked ourselves what they cared about in a development tool, then we created a tool that met those needs. We did the same thing for enterprise and team developers, as well as Web and other major groupings of developers. Tailoring the development tools to the specific needs of particular customers was a major component in how we approached creating Visual Studio 2005.
PM: Speaking of particular groups of developers, there remains a significant number of VB5/6 developers who never made the switch to .NET. Do you think these tools represent our generation’s COBOL, applications that will be maintained more or less indefinitely because they work and the people who commissioned them see no reason to create something new?
SS: The number of VB5/6 developers who have switched to .NET continues to track significantly upward, even over the last year. In one sense, we are pleased at the number of people who continue to make the switch, but at the same time, we know there are more people we need to help encourage to make the switch.
There is a migration cost that cannot be ignored. I don’t want to say you can wave a magic wand and suddenly your VB5/6 developers are all .NET developers, or your VB6 program will suddenly be a .NET application with all the benefits that entails. There is a one-time migration cost for both your developers and each of your existing applications you might want to port.
But one reason we are still excited about the .NET platform is that, if you think about the benefits from a developer perspective or a cost-of-ownership perspective or a security or productivity perspective, there have been several recent studies that corroborate our claims of increased productivity and reliability. These apps have 2.5 times better performance in some cases, or provide better security—these are benefits that are significant enough that developers taking a long-term view can really see the benefit of making the change. These developers will see a return on their investment that is many times over the cost of staying where they are, and they will continue to see this return on investment over time. This is what we at Microsoft have to do a better job of getting across.
On the one hand, there is a cost that I and others at Microsoft are cognizant of. On the other hand, this is a one-time cost, and the benefits to your company and to you as a developer are huge. This is one reason I’m excited about our prospects for getting more VB5/6 developers and companies to make the switch to the .NET platform. We’re already seeing this; I believe we’ll continue to see this.
We are also taking a number of steps within Visual Studio 2005 to make this switch even more compelling. For example, we are adding back edit-and-continue. I know this is a feature that has been missed, but it is back now, along with other productivity enhancements such as MyClasses that will both simplify how you do many common tasks, as well as reduce the number of lines of code it takes to implement some functionality.
PM: I appreciate the points you are making about MyClasses and edit-and-continue, but on the surface, each new release seems to leave these developers further behind. At what point do you simply discontinue these efforts and say, “Well, if they haven’t come yet, they likely aren’t going to”?
SS: There might come such a point in the future, but we’re not there yet. With Visual Studio 2005 and the release that will follow it, we are highly committed to making the transition for VB5/6 developers to come to .NET as compelling and as pain-free as possible. The .NET platform has an appreciable number of benefits; we want to see everyone take advantage of them, and we’re going to continue to do what we can to facilitate adoption among not only VB5/6 developers, but all developers.
PM: Microsoft just released a patch for Windows XP that addresses many of the security concerns with that product. If you were to cast Microsoft’s progress on security in terms of a percentage, how far along would you say Microsoft has come, and how far does it have to go? For example, is it a quarter of the way to where it needs to be? Halfway?
SS: I can’t answer the question in those terms, but I can say that we’re in the process of changing how we approach security, and that this change in approach will go a long way toward creating a more secure, more reliable environment.
Until a year or two ago, we were thinking of security in a reactive way. We’d ship a product, a great product that we felt was secure, but then we or someone else would find a problem, and we’d go fix it. We assumed customers would pick it up, and life would be fine.
But take a look at several of the larger issues we’ve faced, from CodeRed to Nimda to Blaster. In each case, a patch to address the problem already existed before the virus surfaced in the real world that exploited the given hole. One thing that has changed dramatically, though, is that the delta between when we address an issue and when someone creates a virus to exploit the just-fixed hole has reduced dramatically. For example, it took 300 days to a year after we issued the patch for someone to write a virus to exploit the CodeRed/Nimda situation. In the case of Blaster, the time fell to 22 days or something like that.
What has been happening is this: We want to do the right thing, so we put out a patch for our customers. But then there are people who will look at the patches and appreciate that not everyone updates their systems regularly, so they use the patch as a basis for reverse engineering the security hole and then writing a virus to exploit it. We are in this bizarre game of tennis. We, the good guys, are one side. The hackers, the bad guys, are on the other side. No matter how hard we work or how much due diligence we show, the ball is always going to go back to them. What we really want to do is change the game. We want to get to a situation where, when we suspect there is an attack coming on a particular front, we can initiate a defensive situation where we turn on settings at your perimeter that ensure nothing can get into your environment. Once you are in that mode, you can decide on when and how you want the patch implemented, so you can minimize problems or potential issues in your environment when you implement the patch.
With that in mind, we took a proactive approach to security with respect to how we thought about the service pack for XP2. For example, we beefed up the firewall in XP2 and turned it on by default. We also took steps to reduce the surface area for potential attacks, especially in the applications targeted most heavily, such as Internet Explorer. We hardened those things to provide a greater level of security. I feel that we’ve come a long way in terms of reducing surface areas for people to attack applications on our platform, and we have ambitious plans for reducing that further. I can’t give a specific percentage that says how far along we are, but I can say that with XP SP2 and our upcoming offerings, we’ve taken several large steps forward, and several more large steps will be forthcoming.
PM: Microsoft has long incorporated some of the better features of third-party vendors into Visual Studio, and Visual Basic before it. By and large, this has been a good thing, as developers got more functionality out of the box, and the third-party community vendors targeted new needs that developers wanted met. This is happening again, but on a much larger scale, with the incorporation of lifecycle management tools. Why did Microsoft choose to implement its own versions of these tools when there are third-party products that provide many of these services already?
SS: There are a couple reasons we’ve adopted the approach we have.
First, customers have long been telling us that yes, we make some nice productivity-enhancing development tools. However, these customers have noted that we don’t include many team-oriented development tools out of the box. Think about a scenario where you have a bunch of people coming together as a team. You have some product managers, some developers, some customers, and some marketing people. All of these people come together to create a particular product, and they would like well-integrated tools that make this collaborative process more seamless. What we need in this case are not just tools that work well together, but tools that contribute to a uniform flow of information within the team.
Our goal with Visual Studio 2005 Team System was to build a set of tools that were highly integrated and, as is our custom, provide a robust integration model so third-party vendors can come in and plug into tools that facilitate even more cohesive team development. We had a lot of internal debates on the right way to approach this several years ago, when we were formulating our vision for this tool. We knew there was an element of risk involved in telegraphing our intentions, but about 18 to 24 months in advance of shipping these tools, we gathered together our various partners in the lifecycle management tools space and other lifecycle management vendors, and we shared our thinking with them.
Today, that kind of meeting might seem like a no-brainer, but it was something we debated and were concerned about internally. Ultimately, we did it because it was the right thing for us, our partners, and our customers. Our goal was to get them on board and to give them a chance to find new opportunities within an exciting new approach to development, from our point of view. Many of our existing partners continue to play with us, and we’re getting many new partners who see the value of what we’re trying to provide to our customers. Some of the companies who have committed publicly to working with us on Whitehorse/Burton include Compuware, Infragistics, Borland, Micro Focus, and Fujitsu. More announcements are coming down the road, but it would be premature to discuss these now.
PM: How will the inclusion of these lifecycle-management tools affect the everyday developer experience?
SS: Let’s assume I am a developer writing some code. Wouldn’t it be nice for me to have access to the larger design of the application I’m working on? Wouldn’t it also be nice to have tools that review my code, and ensure it meets the quality and security requirements I’m looking for even before I check the code in? More importantly, wouldn’t it be nice, when the quality assurance people test my code, to know immediately what the issues are with my code as they are discovered? The seamless flow of information between the people I need to interact with can have potentially huge benefits for me as a developer. In many cases, workflow and information process management is an added layer that everyone must cope with. The team tools in Visual Studio can help different team members break down the barriers that prevent people from having access to the critical information they need both to create and monitor the development of a particular application or suite of applications.
PM: Global outsourcing is a hot-button topic right now. Are there specific features being written into Visual Studio 2005 or future versions of Visual Studio .NET to facilitate the far-flung development operations you see at many companies these days?
SS: Global development is definitely one of those areas that will play an increasingly important role at many companies, and we will study our tools for ways to improve this type of development experience. For example, Microsoft has a software-development team in North Carolina working on Burton. It has teams in Redmond and India working on Burton. Making this process easier and more seamless is as important to improving our own efforts as it is to improving the efforts of our customers.
What you will see in this area will follow the good, better, best paradigm. Visual Studio 2005 makes such operations feasible, but post v1 for VS 2005, you will see substantial improvements in how our tools accommodate such scenarios.
PM: I know a lot of developers who are worried about their futures. For example, many developers in America have watched in silence (and not-so-silent horror) as high-paying developer jobs move overseas to developers who earn significantly less than their American counterparts do. This is especially true of developers whose primary job is writing code for a living. What sort of future does this person—who is a nose-to-the-grindstone-and-that’s-all-I-ever-want-be coder—have in America right now?
SS: As I reflect on the software-development space around the world, I’d have to say it’s true that the world is becoming a smaller place and that you’ll find jobs that once might have been handled in Indiana are now handled in India. Having said that, there will always be demand for the skill sets of those who keep up to date with the latest technologies and tools, especially among those who learn how to take advantage of them to create new and interesting kinds of applications. Note that your company might not necessarily pay you to keep up with your training; it’s on you as a developer to ensure, whatever your company does, that you remain abreast of current developments and tools to give yourself options, not just in the immediate future, but down the road. We spoke earlier about the VB5/6 developers who haven’t adopted .NET. One reason for these developers to adopt .NET is that it will mean greater job opportunities for them in the future. As long as developers are able to bring value to the process, the prospects for a .NET developer specifically will remain numerous and varied.