.NET Rock Star: Scott Currie (
Page 1 of 4 )
When customers want help on technical topics in C++, Microsoft's Scott Currie is the one they ask for. Learn his views on Visual Studio's new features, the right questions to ask in a technical interview, and the most common developer mistakes.
At TechEd, I asked one of the Microsoft program managers to tell me about some of the smartest people she knew. After thinking for a bit, the name she came up with was Scott Currie, a Program Manager on the Microsoft Visual C++ team. When customers want to talk with
a techie, she said, they always want to talk to Scott.
Ah. I always want to talk to someone that everybody wants to talk to — just to find out why. After reading this interview, which covers topics that range from features in the next version of Visual Studio to the most important question to ask during a programming interview, I think you'll understand the reasons, too.
"All you need to know about me," says Scott, "is that I work every day to create technologies that make it easier to bring existing C++ code forward to .NET, and I'm rabidly passionate about doing the right thing for our customers."
DevSource: I'm told that when people have really technical questions about C++ or Visual Studio, they want to talk with you. Why do you think that is?
Currie: I think it's because I have a lot of technical depth across a broad spectrum of Microsoft developer technologies. Where did this come from? Well, I primarily work on a technology called IJW. I'm sure we'll talk more about IJW later in
the interview. IJW is really cool and enables some very important customer scenarios, but it certainly wasn't easy to build. The technology requires that existing C++ code be recompiled to run on top of the .NET Framework. As it turns out, the C++ programming model is fundamentally incompatible with .NET. Some of the C++ semantics are subtly different from what .NET provides, but even worse is that .NET offers a variety of concepts and services that
C++ neither understands nor respects (e.g. AppDomains and GC handles).
As a consequence, we had to make extensive modifications to just about every component involved in building and running C++ code on the CLR, including the C++ compiler front end, the C++ compiler back end and code generator, the linker, the manifest tool, the CRT runtime and library, the IDE, and even the CLR itself. Of course, most of these changes were highly detailed and exploited the rich interdependencies among all of the involved components. To make this work, we needed someone — with knowledge about the details of those components and their interdependencies — to lead the design of new IJW features and to help resolve issues that came up while implementing them. For Visual C++ 2005, my team and I filled that role.
Since one of the IJW feature designs I worked on will have touched just about anything in Visual C++, I'm usually a good person to talk to about broad technical issues. I also had to build relationships across and outside of the team in order to make all of the collaboration on these features work. I got to know many people on the team really well. Each of these people learned a lot about what I'm good at and I learned a lot about what they're good at. As a result, they know when I'm the right person to talk to about a particular issue. Even better, if they don't know who to talk to, I can usually point them in the right direction.
DevSource: What's the last program you wrote for your own pleasure, not for someone else's use? What did it do?
Currie: I wrote a policy-based template metaprogramming library abstraction over managed DirectX.
I've always had an interest in 3D rendering and, conversely, machine vision. Lately, I have been working on a few demos that use 3D visualizations, such as the Rubik's Cube Solver).
More importantly, we've been working with some customers that use a lot of 3D graphics, and are looking at moving more of their applications to .NET. I'm never very comfortable entering into problem solving situations with customers unless I feel confident with all of the technologies that are in play. It's too easy to do the wrong thing, and only realize it after spending hundreds of hours of customers' time.
So, I dove into DirectX and Managed DirectX programming, internals, everything I could get my hands on. As I wrote sample code and played with various features of both the fixed and
programmable pipeline, I started to experience quite a bit of pain around making some fairly basic changes. If I wanted to do something as conceptually simple as swapping out lighting models, I had to go and make significant changes in five completely different places in my rendering engine source code.
Coming from a hardcore C++ perspective, I saw a perfect opportunity to leverage template metaprogramming (which is a technique for generating code at compile time using the C++
template construct). Specifically, I could abstract each of my DirectX choices, such as lighting models, as a set of rendering policies. I decided to spend a few weekends to design the policy hierarchy and write policies for common DirectX constructs. These rendering policies factored into a policy based template library which forwarded everything to DirectX, but exposed a much cleaner, more centralized model than the DirectX APIs themselves. With this
library, complex policy decisions can be changed by modifying a single line of code. Additionally, since much of the common DirectX overhead code was factored into a convenient, extensible library, the total amount of user code in my engine decreased by 90% when I modified it to use my policy-based template library.
As it stands, this was just a hobby project that I wrote in my spare time, but I have approached the DirectX team about it. Who knows? Maybe I'll get the chance to release it to the community. (By the way, if you're interested in learning more about policy-based
template libraries, you can find plenty of detailed information with examples in Alexander Alexandrescu's Modern C++ Design (Addison-Wesley, 2001, ISBN 0201704315).)
DevSource: What's the last book you read?
Currie: I just finished The Paradox of Choice: Why More Is Less by Barry Schwartz (Ecco, 2004, ISBN 0060005688). It examines the trend toward an ever-increasing number and complexity of choices in our daily lives, how these choices are made, the pain that they can create, and how they can affect overall satisfaction with the products and services about which the choices are being made.
While I disagree with many of his conclusions, Schwartz introduces an interesting framework for analyzing the sources of pain in the decision making process. Developers have to make hard choices all the time, from high level architecture to which Windows API to use when implementing a small piece of a specific feature. Microsoft isn't doing a great job of making these decisions easier for our customers. We pride ourselves on the fact that there are at least five ways to do anything. This gives our developers the power and flexibility to solve their hardest problems.
But we need to give more guidance about which of those five options to choose when just trying to solve an easy problem. We have limited discussion of this in documentation and some guidance articles, but that's it. I think that this creates real frustration for customers, and it's something that I'm going to work to try to address.
