My History of Visual Studio (Part 9)

[All the other Parts: History of Visual Studio

In the last posting I talked about the “Whidbey” release, VS2005, but I feel like I left out two really important aspects so I’d like to start this part by rewinding a bit for those two topics.

I had mentioned in Part 7 that some of the UML support in the “Everett” time-frame was starting to foreshadow the release of VSTS.  Well, in Whidbey there is no foreshadowing disclaimer necessary – VSTS arrives and I think at that point it’s clear that Microsoft is going to try to have a real offering in the ALM space.  I think it’s fair to say that the venerable VSS was not going to be the product to carry us into the 21st century.

I don’t want to understate the difficulty of bringing just TFS to market, and that’s only one part of the equation, but even giving those hard-working folks a well-deserved nod, I felt like the first VSTS was just a taste of ALM at this time – whetting the appetite as it were.  But even so, with so many shops wanting to formalize their practices in some way – even lightweight practices like Scrum – this kind of support was welcome relief.  I think those years included a much greater level of attention to the process of creating software than at any other time in my experience. 

Just 4 years after its initial 2005 release, VSTS is a huge part of what we deliver – and in 2002 it didn’t even exist.

I started my discussion about the Whidbey release with an observation about how big of an influence Windows Vista was on our tools.  I think I should have ended with my single biggest regret about that release because it’s highly related.  Despite its huge influence, our support for Windows Vista was lousy in the initial release, like really lousy.  It wasn’t until we delivered SP1 and especially the Vista support for SP1 pack that we got to a reasonable level of support.  I could make a bunch of excuses but they all sound pathetic to me so I’ll just stick with “It’s my #1 regret.”

OK so much for the downer part of the article; let’s move on to Visual Studio 2008 “Orcas.”

The thing that I most remember about “Orcas” is “MQ” – the Quality Milestone.  This is where we spent the equivalent of an entire coding just taking care of nagging issues that otherwise seem to not get handled. I’ll name-drop again since I just linked her video, I’d have to say it was Carol more than anyone else that was keeping us honest about the “debt” we had accumulated in our product and popularizing that meme in our division.  Debt is a great way to think about trade-offs: every time you make a choice that isn’t right in the long term, any short-cut, accumulates some debt.  Any bug you choose to defer, that’s debt.  Some debt you should write-off, that fix just isn’t happening, some you should address, but always you should be aware that you’ll have to deal with it sooner or later, and it may as well be sooner.

That mind-set, which was the focus of MQ was pervasive for the whole release, and I think it shows.  From a stability and performance perspective VS2008 was universally better than 2005 – a very hard thing to achieve in any major release with significant additions.

I think the “star” of VS2008 was Linq – my favorite flavor was “Linq to SQL” which I’ve written about at some length before.  Perhaps the most amazing thing about Linq is that its introduction into both C# and VB allowed mainstream programmers to start using functional concepts in a natural way, often without even realizing it!  But a close second are two other amazing things: 

1)      Linq variants (Linq to XXX) started appearing like crazy – the notation was incredibly useful

2)      You could actually get great performance out of this kind of layer without inflicting craziness on users (see my article again for the Linq to SQL discussion)

In the same way that the needs of high quality designers drove advances like partial classes (critical for code separation) Linq variants and their needs, drove the type inference, extension methods, and expression tree features, including concise lambda notation, necessary for its success into the mainstream languages.   This brings great collateral benefits because those exact same notions are helpful in so many other scenarios – I use them pervasively in my WPF code for event handling for instance.

As usual this all comes at a cost, it’s not just language notation: it’s also the debugging support, profiling, garbage collection, FXCOP, and so on.  After all, just because a method is dynamically generated, has no name, and no .pdb file information, doesn’t mean you don’t want to analyze it like the others.  And of course the ability to generate expression trees in addition to IL represents another significant undertaking for the compilers.  All of this is fundamentally necessary for Linq to succeed but it’s kind of invisible – it’s the stuff you expect to just work.

“Orcas” also included the “Cider” designer for WPF. Remember that during this period there had been several runtime releases including 3.0 and it shipped alongside 3.5 of the framework.  Well by the WPF was a first class application target and it needed designer support and the richness of WPF resulted in perhaps one of the most complicated designers ever created. It’s doubtful that a successful designer could have been created if not for the lessons from “Sparkle” aka Expression Blend, and language advances like partial classes to ease things along.

The abundance of framework subsets led to the need for multi-targeting – that is the ability of the tool to target any one of several framework versions or to have solutions with projects targeting arbitrary combinations.  This was tricky enough in Orcas but at least the frameworks all shared a common core – simplifying things significantly.  That grace would be absent in the follow-on release VS2010.

Other application models were popping up as well – Silverlight had made its debut, taking WPF concepts to the web, and Windows Workflow (WF) also delivered a release and a designer.  If it wasn’t already de facto reality, the general theme that “every application model needs a suitable design experience” was certainly cemented during this period.

Debugging technology takes itself to new amazing places like XSLT debugging (XSLT makes my head hurt even more than APL) and gains the ability to debug into the BCL and dynamically download the source as needed to do the job.   Very slick, but by now you know I’m partial to debugging technology J

And on the native code front, MFC 9 makes its appearance – adding support for new Vista concepts, and representing the first significant update to MFC in a very long time.

But for me the biggest memories are just working on performance across the board, from MQ to the finish.  In the framework, in the tools, we made big dents in many scenarios and overall, even with lots of new features, Orcas felt snappier than Whidbey which was a great accomplishment.  I loved using it!

I just hit 1200 words so I think it’s time to stop, having skipped vast regions and barely mentioned VSTS, I’ll pick up again in a bit. 

Thank you for all the feedback and comments, they’re much appreciated.

[See The Documentary on Channel 9!]

Comments (1)

  1. AndyC says:

    I have to say it’s nice to finally see someone from Microsoft put their hands up and admit the VS2005/Vista situation was all just a bit poor. I recall being on the receiving end of a whole raft of excuses, none of which stood up to much scrutiny.

    Fascinating series of posts though, it’s quite amazing how much developer tools have moved on, it really never ceases to amaze me. When I think back to the kinds of tools I started on in the early 80s and compare to what we have now, I can hardly even begin to comprehend the changes. What will we have in another 25 years? The mind boggles….

Skip to main content