Share via

The Visual Studio Diagnostics team

  • Article

I thought I'd share a little bit of organizational info about the team I work in as a way to dust off this old blog. I'm trying to make sure I don't leave it as dusty as I have been prone to.

About a year and a half ago, I worked with a few folks in the VS organization to bring the debugger team and profiler team into one umbrella org we call "VS Diagnostics".  The team is not a huge one and we cover a variety of efforts including all of the native and managed debuggers (x86, x64, IA64), T-SQL debugging, SQLCLR debugging, Script debugging, Code coverage (managed and native) and Profiling (managed, native, x64, x86).

Obviously that's a bunch of work for a team in the low 10s of people (I don't think I am stepping over the line there, but if Soma wanders into my office it could be that "I'm just going outside; I may be away some time.").  We believe, and feel free to correct me if I am wrong, that powerful integrated debugging and diagnostic experiences are some of the reasons our customers love VS.  But we think there is room for improvement.  Essentially, the way we debug and diagnose issues has not radically improved in the last 15 years.  Now look at the same period in software construction:

1) Libraries have moved on, there are many declarative based paradigms (think things like WPF), and a myriad more frameworks than plain old VBRun, Win32 and the CRT.  These platforms and frameworks have become more complex and require a bunch of domain specific knowledge for people to understand them.

2) The support for automating construction has evolved with numerous wizards, designers and code samples

3) The code editing experience is now so much richer with intellisense and refactoring

Creating VS Diagnostics has given us the potential to drive forward on a number of fronts including:

1) Building a platform core that is flexible enough that framework builders can provide the right diagnostic experience for their framework

2) Building a much more extensible core of diagnostic technologies than we have done to date.

3) Developing new experiences and paradigms for how people solve problems with their software today.

We still take very seriously our need to support our existing customers, so we're working to ensure Orcas is a quality release, and understanding which features we can build that remove people's current dissatisfaction with the debugger and profiler.  We're hard at work in all of these areas.  We know that our work touches every developer, but it's that very touch that keeps us coming to work every day.

My job at the moment is Development Manager for this group, which I've done now for close to a year, and it has been some of my best time at MS.  I'm really happy to see the stuff we got done for Orcas, and am looking forward to more in the releases beyond, including the upcoming Rosario.  Stay tuned for further posts on Rosario as and when I can in the coming months.

 Cheers,

John

Comments