The history of Microsoft’s developer tools and technologies is in many ways the history of the company itself. And nothing speaks to the transformation that is happening now at the software giant quite like the transformation we’re seeing across its developer stack.
This history likewise parallels my own history in the industry, as I got my start as a developer and as an author of books about Microsoft developer technologies. But I’ll be telling that story in other articles in the near future. Here, I will present a behind-the-scenes look at Microsoft and its developer technologies—then and now–as told by some of the people who have experienced it—are still experiencing it—first hand.
By way of background, however, it helps to know how we got here. And the short version goes like this.
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
As most probably know, Microsoft’s first product was a version of the BASIC programming language designed for the Altair 8800. But Microsoft—or Micro-Soft, as it was originally known—had bigger plans than the Altair. And by the mid-1980’s, versions of Microsoft’s BASIC language had shipped with virtually every personal computer released during this period, including the Commodore computers that first piqued my interest in this topic.
By this time, Microsoft was well on its way to becoming a platform maker, through operating system releases such as MS-DOS and, later, Windows, and via productivity software like Excel. But the firm never walked away from its developer roots, understanding innately, perhaps, that its success relied on healthy software ecosystems.
So it brought BASIC to the IBM PC and its clones via GW-BASIC, QuickBASIC, QBASIC, and other efforts. It provided a C language environment originally called Microsoft C, and a Microsoft Macro Assembler (MASM) for MS-DOS and, later, Windows for those developers that wished to get as close to the metal as possible.
By the mid-1990’s, Windows had taken the industry by storm, and Microsoft’s developer efforts had evolved to address this change via two key products: Visual Basic, which introduced a truly visual way of creating user interfaces, and Visual C++, which consolidated the firm’s C and C++ languages and provided an object-oriented Microsoft Foundation Class Library.
This is where I enter the picture: I had gone back to school to become a developer, and while doing so, I made the transition from DOS-based developer tools like Borland Turbo Pascal and Turbo C to Windows-oriented tools such s Visual C#. I was fascinated at the time by the event-driven programming model that Windows and other GUI systems delivered, and by the rapid improvements being made to the developer tools that made it all possible. It was a major part of the reason that I transitioned onto Microsoft’s platforms.
This was when Julia Liuson, now the Corporate Vice President of Visual Studio & .NET at Microsoft, entered the picture. She actually joined Microsoft in 1992, as a developer out of college, and initially worked on Access, a database application. But by the mid-1990’s, Microsoft had big plans to consolidate its various, still separate developer tools. And Liuson went along for that ride.
The result, of course, was Visual Studio. Initially code-named “Boston”—as you may recall, Microsoft utilized a lot of city-based codenames in the mid-1990’s—Visual Studio was envisioned as a sort of Microsoft Office for developers. That is, in its first rendition it would package all of the modern tools together in an affordable package that would allow developers to access unfamiliar products. And then integrate them more completely in subsequent revisions.
The first version of Visual Studio shipped in early 1997 as Visual Studio 97 because, wait for it, Microsoft was caught up in the post-Windows 95 euphoria of using date-based versioning in its product names by that time. This bundle included updated versions of familiar tools like Visual Basic, Visual C++, and Visual FoxPro (a developer-oriented database solution). But it also included some new tools, such as Visual InterDev for web development and Visual J++, Microsoft’s Java environment.
“I joined the Visual InterDev team on day one, in early 1996,” Liuson told me in a recent interview. “It was a fun product to work on for a few years. At the time, we called it ‘Visual Basic for the web’.”
Visual InterDev—and the entire Visual Studio 97 suite—was a fast release, she told me, taking just over a year to come to market. And bundling those products together was indeed a “business changer,” as Liuson said, opening up new tools to a wider audience. As important, it evolved Microsoft’s developer stack to address new markets like the World Wide Web, databases, and server applications.
The various developer products in Visual Studio 97 were complementary, but they weren’t integrated in any way beyond the ability to use extensions written in one language in the other environments. So for the second version of the suite, named Visual Studio 6.0 because of course it was, Microsoft began the work to bring all of the tools together. It was the beginning of Visual Studio as we know it today.
“We used version 6.0 because that was the version number of Visual Basic at the time and we lined up the version numbers,” Liuson explained. So Visual Basic and Visual J++ made big jumps from 1.0 to 6.0 in that release. And Microsoft stepped back from—temporarily, as it turns out—from the year-based version numbering as well.
After Visual Studio 6.0, Microsoft dropped Visual J++ because of some legal issues with Sun, a momentous change that ushered in the .NET era and Microsoft’s in-house effort to create a viable Java alternative, which it called C# (“C sharp”). This change also coincided with the move to a single integrated development environment, or IDE, for all of the core supported languages. This was clearly the right move, but it also resulted in the end of what is now referred to as the “classic” versions of Visual Basic. Today’s VB more closely resembles C# than it does the VB of the past.
“During the Visual Studio 2002 development cycle, I managed the VB team,” Liuson said. (VS 2002 was version 7.0 of the product.) “This was an incredibly impactful product. In fact, there is still enterprise software built on VB 6 that is still running out there.”
Her fondest memory of this time? “We received a letter from a devoted user that was addressed to ‘Bill Gates and the Visual Basic product team’ thanking us for changing their lives. They were able to learn software development with this tool, and they became professional developers.”
But .NET was the future, and that meant that VB needed to grow up too.
“Visual Basic .NET was an interesting transition,” she told me. “It was basically version 7.0 and 1.0 at the same time because of the massive rewriting effort.”
Indeed, Visual Studio was itself undergoing a massive rewriting effort to accommodate .NET.
“People often think of a product like VB 6 as three different things: the language itself, the runtime, and the tools,” Liuson explained. “But they all intersect. The runtime and the frameworks dictate the language capabilities, and with VB .NET and C#, we were building on the .NET Framework. It was a key strategic decision and a major change.”
Subsequent Visual Studio versions provided key enhancements as well. After a minor update with Visual Studio 2003 that was aimed at supporting the .NET Framework 1.1 release, Microsoft Visual Studio 2005, which started the push to team-based development, an effort that was led by Liuson. Later, Visual Studio 2010 introduced support for the F# programming language and LINQ, a way to query databases using .NET programming languages. It also introduced the code editor that developers are still using—in updated form, of course—in Visual Studio today.
And then Windows 8, and Visual Studio 2012, happened.
“That’s the one where we didn’t get to set our own shipping schedule for the first time,” Liuson told me. “Instead, the schedule was based on the schedule for Windows 8. From Microsoft’s perspective, this was about recognizing the importance of mobile and consumer touch devices. Windows 8 was out there trying to address that market, and it was a big release for us in Visual Studio.”
Windows 8 was disruptive for virtually everyone in the industry, but I was surprised to discover that Liuson seemed to enjoy the challenge. (She assumed her current role as CVP after Windows 8 and Visual Studio 2012 shipped.)
“It was complex trying to ship Visual Studio with Windows 8,” she told me. “We had to support the Windows app runtimes, onboarding to the Store, and so on, and ship a new SDK on time. It was super interesting getting it all to come together.”
But the Visual Studio team’s experience with Windows 8 also drove some decision making that would impact future releases.
The first was to address the need for faster product releases. “Before that, we’d ship new Visual Studio versions on three-year release cycles, for the most part,” she told me. “But we wanted to have a much faster cadence post-2012, with updates arriving on a roughly quarterly basis.”
These updates wouldn’t just be bug fixes, either. They would include significant new features as well.
“We’ve really embraced our internal Dev Ops mentality,” Liuson told me.
The second major change was reflected a sea change that was happening—and is still happening—at Microsoft more broadly. Visual Studio was among the first groups within Microsoft to really embrace open source.
“We decided to open source our next-generation compiler, which was called Roslyn,” she said. “We announced that at Build 2014. And later that year, we announced an even bigger effort to open source .NET. These are significant pivots.”
Moving to an open source model allowed Liuson and the Visual Studio team to really embrace what its customers were doing and involve them more deeply than ever before in the creation of its entire developer stack. It led to the mobile development advancements found in Xamarin, and to cloud-based solutions in Azure and the cross-platform .NET Core technologies.
Over the year, Liuson experienced several strategy shifts for both the company generally and for Visual Studio specifically. But many of the people working on the product today come from very different backgrounds and have very different experiences. And Microsoft’s recent embrace of open source has been particularly opportune for this new generation of employees.
Take Microsoft Senior Program Manager Mikayla Hutchinson, for example. After being mentored by none other than Miguel de Icaza at a Google Summer of Code in 2005, Hutchinson fell in love with C# and with the Mono project that Miguel was then focused on. After a second Summer of Code in 2006, she joined Miguel at Ximian, which was then part of Novell, in Boston in 2007. She worked on development tools for business apps on Linux.
After the entire group was laid off by Novell—or, by Novell’s parent company, Attachmate—de Icaza and Nat Friedman co-founded Xamarin in order to continue Mono development and focus on mobile. They hired virtually everyone from Ximian, including Hutchinson. And got back to work.
Mono was an effort to bring .NET to Linux, initially, and to other UNIX-based and UNIX-like systems. It was legal in that .NET was an ECMA standard, and while Microsoft formally had no official stance on the project, many of its employees were quietly cheering on Miguel and company, and helping them in any way they could. Mono was of course later brought to Android and iOS, the most popular mobile platforms.
Hutchinson originally took an architect-type role at Xamarin and floated between projects for both Android and iOS. “I helped create our activation system,” she told me, “and I worked on an Unreal Engine project that eventually never happened.”
About two years ago, she transitioned to Program Manager, where she likewise floated between different projects, like Visual Studio extensions, SDKs, and mobile. But she’s since worked on Xamarin Studio for Mac, which was renamed to Visual Studio for Mac when Microsoft purchased Xamarin last year.
“Last year, we announced Visual Studio for Mac as the evolution of Xamarin Studio,” she told me. “The big change is support for ASP.NET Core web services, so developers can now build both the app and its back-end.”
Previous to Microsoft’s embrace of open source, porting .NET technologies to Mono required a lot of work. But with the advent of Roslyn and the broader open sourcing of .NET, Xamarin has been able to make a lot more headway.
“We were working with Microsoft long before the acquisition,” Hutchinson said. “They’ve been championing our work since the beginning.”
Hutchinson and the rest of the Xamarin team still works largely out of Xamarin’s Boston offices, and she says that Microsoft has mostly left it to its own devices. (About half the team is remote.) But the addition of ASP.NET Core web services to the product this past year “was not something we had on our roadmap,” she told me. “But now we’re part of a bigger vision, a bigger story.”
The Microsoft acquisition has likewise given Hutchinson and the Xamarin team much better access to the people elsewhere at Microsoft who they were interacting with before the change.
“Yeah, I probably spend more time in emails and meetings than before,” she admitted. “But it’s interesting work, with smart engineers and amazing people. We are making things happen that we couldn’t do before.”
Hutchinson noted that during her time at Novell, Microsoft seemed largely standoffish because the firm did not officially support open source. But that’s over, a different and long-forgotten era.
“Open source has really taken root inside Microsoft,” Hutchinson said, “and attitudes have changed enormously. There is so much visibility into what is happening with C# development on GitHub, for example. Our language design meeting minutes are published for the community, and they can submit issues and ideas, and discuss them with the team members. It’s such a huge change.”
For Xamarin specifically, just being part of Microsoft has been a huge change as well: Once you put technology directly into Visual Studio, as Microsoft did with Xamarin Studio functionality on Windows, the user base explodes.
“Last year was incredible,” she told me. “Our user numbers shot through the roof. My favorite part of this job has always been writing developers tools and seeing people use them to make great products of their own. That being available and accessible to so many more people—the reach—is amazing.”
Where Hutchinson had dealt with the software giant before its open source epiphany, Microsoft Program Manager Phillip Carter has never known a world in which the software giant was anything other than fully transparent and open. He works on documenting the F# programming language and integrating it into Visual Studio.
“F# was my favorite programming language in college,” Carter told me, noting that his college development experience was entirely based on open source solutions. “It was awesome. It was just the way everyone worked.”
Carter joined the .NET team at Microsoft in 2015, when it was already pushing into open source. So he’s never known a Microsoft at which this wasn’t the case.
“This is very natural to me,” he noted.
I was curious whether he’d run into any problems with an old-school contingent that is perhaps less excited by the move to open source. But he said that has never happened.
“Everyone I work with is super happy to be working this way,” he answered. “We engage directly with our customers, and they have a vested interest in our combined success. The barrier between our developers and the outside world has been lifted, and the product is significantly better as a result.”
Seriously?
“I have had no issues at all,” he continued. “There isn’t one person who didn’t like this shift; developers, program managers, directors, whatever, all of them loved it.”
“Look, this is making .NET mindshare better too, making it more relevant, more sincere” he said. “It’s weird how software can feel sincere. But the day-to-day stuff is out there on Github, not hidden inside some internal repository. People are just blown away by this.”
That interaction with the customer base, the users, has emerged as a key topic in all of the conversations I’ve had with the Visual Studio team recently. It’s interesting that the real advantage of open source isn’t so much actual source code access per se, though that is available as well, but rather the transparency, and the conversations that happen. By contributing to the product from the outside, the users are essentially team members and become just as invested in the product being as high quality as possible as those inside Microsoft.
“F# is a great example of this direct engagement with people,” Carter told me. “The community has made formal requests, but they’ve also initiated major new language and IDE features.”
Developing products like this in the open also gives those inside Microsoft a greater sense of purpose because they’re not answerable to a single manager inside the company. Instead, there is an entire community ensuring that work gets done, and done correctly.
“Now our users are empowered and even have ownership over the language itself,” he said.
Kasey Uhlenhuth, a Microsoft Program Manager who currently focuses on developer tooling for the C# developer experience, has likewise only known an open Microsoft: She joined the software giant in 2014 straight out of college. It was an auspicious time, as Microsoft was then making another important transition.
“I joined at the best time,” she told me, “just as Microsoft was getting a new CEO. The place was ripe with opportunities and changes.”
Her first job at Microsoft, working on the Roslyn compiler, was already “an open source team,” she says. “All of .NET went open source and cross-platform as I arrived. It was awesome.”
Microsoft embracing open source is one thing, but I was also curious about the attitudes towards Microsoft in the academic community at the time. But no, her experience then led her to be quite open to Microsoft.
“I studied CS, and one course about UX, or user experience, was particularly compelling,” she said. “The professor was from Microsoft Research and he was solving real problems for real customers. Lots of people from that class went on to work for Microsoft.”
Uhlenhuth’s experience with Roslyn at Microsoft is emblematic, in many ways, of the broader changes happening at the company. Roslyn is an open source replacement of Microsoft’s proprietary compiler technologies and the keystone of its modern developer stack. In rewriting it, Microsoft made the compiler “better” of course—it’s more modular and new features can now be added more quickly—but also more open and transparent.
“Now anyone can make open source APIs based on this technology, anyone can do their own refactoring,” she said.
When Uhlenhuth joined Microsoft, she was responsible for a single feature in Visual Studio 2015, which was well on its way to completion at that time. For Visual Studio 2017, which is shipping next week, her responsibilities have expanded to a bigger piece of the C# developer experience, including refactoring, code analysis, navigation, and IntelliSense. (Other PMs work on the project system, the language, debugging, and Live Unit Testing.)
“We’ve prioritized this experience on developer productivity,” she told me. “And we spend most of our time trying to figure out how to make developers more productive, and together we find the bottlenecks, and prioritize.”
“Today, we have an open communications channel between our team and the community,” she added, noting a number of community-driven bug fixes and IDE improvements.
Indeed, Microsoft is effectively creating and improving its developer products and technologies in the open today, alongside an active community that feels a sense of ownership and responsibility. New features sometimes come directly from Microsoft, but more often than not they come from the community.
This all makes sense. But for those of us who have been around for a while—OK, for a few decades—this change is nothing less than incredible. That there are people working at Microsoft who have never known any other way is all the more incredible.
“It’s a brave new world,” Liuson told me, referring to this sea change. And the coming version of the product, Visual Studio 2017, will reflect that change while remaining true to the product’s history.
“I’m super excited about this upcoming release,” she said. “We have a new generation of developers who are building mobile first, cloud first apps. And all of this is built on that two decades of innovation while remaining rooted in where developers are today.”
skane2600
<p>In my view DevOps and quicker release schedules are a fetish that decreases quality and has little positive impact on customers or the bottom line of a company.</p>