Architecture Journal Profile: Scott Guthrie

 

Scott Guthrie is a general manager in Microsoft's Developer Division. He runs the development teams that build CLR (Common Language Runtime), ASP.NET, WPF (Windows Presentation Foundation), "WPF/E," Windows Forms, IIS (Internet Information Services) 7.0, Commerce Server, .NET Compact Framework, and the Visual Studio Web and Client Development Tools. As part of the new Architecture Journal Profile series, Ron Jacobs sat down with Scott to ask him about his career and thoughts regarding architecture. (Click here to go to Scott Guthrie's Career at Microsoft.)

RJ: Today, we're going to talk about you and your career for people who think, "This sounds like a cool job." What's your role now at Microsoft?

SG: I run our .NET developer platform group. This group includes the CLR (Common Language Runtime), the .NET Compact Framework, IIS (Internet Information Services), ASP.NET, Atlas, Commerce Server, Windows Presentation Foundation, Windows Forms, and our development tools for targeting Web applications in Visual Studio.

RJ: Wow, that's a lot of surface area!

SG: It's a lot of fun. It encompasses our core application models, the runtime, the tools, and all the engines they run on top of. It's a lot of cool stuff, and a lot of things to play with.

RJ: Most people will remember you from your association with ASP.NET. Let's go back to the early days here at Microsoft. How did you get started?

SG: I started with the IIS team back in '96-'97, working on our core Web server technologies, and was involved in shipping a version of IIS. After IIS 4 was released, we started looking at next-generation Web programming model pieces. At the time, we thought, "Maybe we're done. Is there anything left to do in terms of feature set?"

We started talking with a lot of customers and looked hard at the types of applications they were building. We very quickly learned that there was still a lot left to do. People were struggling with code/ content separation and how to write clean code. We used to joke that "write once, read never" code was being produced. From a tooling and runtime administration perspective, there were many challenges in making our existing infrastructure work really well. To help make this happen, we formed a small team to think about future architectures with IIS. This is the team that invented the HTTP.SYS kernel driver that we introduced with Windows Server 2003. With a colleague, I started looking at Web programming model pieces and wrote the initial prototype for what became ASP.NET.

RJ: It seems that you were thinking of taking this to the next level and taking advantage of something that was super secret at the time. I remember those days of .NET; you used to call it ASP+ back then.

SG: We originally called it XSP; and people would always ask what the X stood for. At the time it really didn't stand for anything. XML started with that; XSLT started with that. Everything cool seemed to start with an X, so that's what we originally named it. In the first six months, we didn't use .NET. The CLR didn't exist—it was just starting around the same time we were—so, we were doing most of our prototyping in C++, JavaScript, and ActiveScript script engines. We knew we wanted an object-oriented environment, and we really liked the characteristics a managed programming model provided in terms of garbage collection, nice encapsulation, and object-orientation techniques. We actually started writing production code in C++, though, because at the time we didn't really have a good runtime platform on which to build. We got about two weeks into it when we met up with the CLR team; at the time that team had no partners inside the company building on top of them. The only compiler they had was this thing called "simple managed C," which we affectionately called "smack." We ended up saying, "Maybe we should build on this." It was a huge risk, and at the time our team consisted of three or four people total. We were allowed to take a bet on it mainly because nobody really cared if we failed. Thankfully, we did and it paid off in a huge way. The rest is history, so to speak.

RJ: I remember those days. In the early days of the CLR, few people were willing to take that bet. Many teams said, "I don't think so," but you guys did, and it paid off in a wonderful way.

SG: Yeah, people were just terrified of the whole idea of garbage collection on the server, which we take for granted today. They said, "There is no way you can build an app with garbage collection running in the background. Your server will never scale." There were lots of doomsday scenarios. From a project perspective, one of the things we did paid off in a huge way. We said, "We're going to bet on managed code, and it won't be a wrapper around some native stuff. We're going to bake it deeply into the platform. We're going to write about 95 percent of our code in managed code itself."

The reason we did that was twofold. One was to take full advantage of the extensibility it provided and really bake object-oriented extensibility very deeply into the platform. And, second, we knew that customer applications would be managed code and that our percentage of code on a call stack would be relatively small compared to the customer's share. If even we didn't think we could write in managed code, we were kidding ourselves if we thought customer applications would sail. It was a great forcing function. From day one through creating more complicated samples, we were tuning the core CLR engine along the way, and that translated into a huge customer savings when we started getting more complicated customer applications on top. It was a good bet.

RJ: It's interesting that you look at this as a way to drive improvement down into the engine. You said, "Not only are we doing this, but we're making the engine better by doing so."

SG: I think that was a huge bet, but it was an approach that worked out well. The fact that we were a small team and starting with a new code base helped tremendously. If we had been a larger team or had an existing large legacy code base, it would have been more difficult, because COM interoperability didn't exist back then. But the fact that we were starting from scratch and able to start small really helped drive those core improvements deep into the engine. As we got bigger and our feature set flushed itself out, it just kept paying dividends.

RJ: I think it's cool that the people who were managing you let you make that call.

SG: It was definitely a gamble, but it was a calculated one. There was a huge upside if we could make it work, but the downside was that there were three or four of us, and we could always do something new the next year. Microsoft has often made these big bets, and usually they pay off in a big way. Occasionally, they don't—and they can fail spectacularly—but, as a company, we try to make sure that we bet big on a couple of key things.

RJ: Did you have to persuade anybody to let you take the risk, or was it easier than that?

SG: We certainly had to persuade a number of people along the way. One thing we did early in the project was get running code in prototypes that we could show people. Often when you're working on a project that's new or something that hasn't been done before, it's easy to put together a bunch of PowerPoint slides that sound good, but it's especially valuable to actually show code and walk people through code that's running. Not only does the prototype prove that it's real, but also you just learn a terrific amount by doing it.

One of the things I try to do with my team is to prototype early, build sample apps early, especially demo apps that we can walk the customer through and say, "Look, here's how you can build an app." We try to do that as early as possible to learn what works and what doesn't, so we can react accordingly. About a month and a half into the ASP project I wrote a prototype, and we were able to walk people through. Here was this component control-driven model—we didn't call them controls back then; they were declarative tags or components—and here was this event-driven way to program for the Web. We were able to build apps and discovered quickly that some of the things we had come up with were really impossible to code. At the same time, we learned that "it would be really cool to have this feature, or that feature," and we iterated along the way. That helped tremendously when we were trying to help people realize that we weren't complete lunatics. We were able to show code, and they were able to get it. It was still a gamble.

RJ: It almost sounds like the test-driven development mindset. Let's do short iterations; let's get to something that works. We'll eat our own dog food, and we'll write against our own APIs to understand what it feels like to use them.

SG: It's definitely the same type of principle. I differentiate between test-driven development as a methodology for how you can drive quality early and how you can provide a base that lets you refactor and adapt your code base without having to worry about regressions. We certainly follow that philosophy internally when we develop production code. I think there's also value in doing a prototype phase even before you get to production code. That's one of the successful things that we did with ASP.NET. We said that we're going to throw away every line of code we're going to write for the next couple of months. Let's all agree on that. We're not going to say, "Oh let's take this and adapt it; we can clean it up." No. We're going to throw it away. We're going to "deltree" this subdirectory at some point, and that way we can be more adventurous about trying new things. We don't have to worry about making sure that everything's robust because it's going to be in the final version.

We actually did that for a few months and said, "We're done, delete it; let's start over from scratch; now let's write the full production code and make sure we bake in quality at the time." I think a lot of teams could benefit from that. The hardest thing is making sure you delete the prototype code. Too often, projects develop with "Well, it's kind of close." It's very difficult to start with a prototype and make it robust. I'm a firm believer in starting with a prototype phase and then deleting it.

RJ: It demonstrates that we value the learning more than we value these files and these bits from the prototype phase.

SG: Every time you work on a project, if you rewrite anything, whether it's from scratch or not, the code gets better. Partly, it's because you understand the problems and pitfalls of the last approach and can reflect and improve on it. The challenge is that you can't easily do that time and time again. But when you're first starting out on a project or a brand-new area where it isn't clear how you get from Point A to the finished product, having a dedicated period where you prototype and try things out is super valuable.

RJ: Some people call that the "architectural spike." Here's a new area, and we're going to explore. Changing directions, though, what were you doing before you came to Microsoft?

SG: I actually joined Microsoft right out of college. I interned with Microsoft while I was in college. I was involved in a couple of startups in college and high school, did some development, and had some fun there, but I joined Microsoft straight out of college.

RJ: We've been talking to a lot of people who find architecture interesting. There seem to be very few people who are purely architects in that they just design stuff and never write code. Most people are a mix: They spend some time developing, some time architecting. What advice would you give to somebody who has been doing development but wants to do more architectural thinking?

SG: Writing code is valuable for an architect. Not necessarily production code you check in, but constantly trying out new technologies, new approaches, and feeling how the system works. I don't write a lot of production code these days, but I spend an hour or two every day writing code. It may be samples, prototypes, or some fun personal project—whatever it is, I'm trying things out, thinking of ways to structure things. Being hands-on is very valuable from a code architect's perspective.

The other thing I would recommend is taking a look at core systems theory and how to architect very robust systems. Consider some of the principles you want to think about and apply them as you're doing it. That doesn't mean thinking about what the lines of code look like, but thinking about simplicity, or robustness, or fault tolerance. Those types of things are core in successful systems; whether it's a client application, server application, or a game. An architect who thinks hard about those kinds of principles and can marry them with a good coding background can provide a tremendous amount of guidance to teams.

Those principles are not about playing with a wizard or checking out cool new stuff, but studying how the process-address space works in a Windows or Unix application. What is threading, and how do you deeply internalize what it looks like on a multiprocessor or multicore system? It's about absorbing that type of knowledge, thinking about its ramifications, and spending some focused time thinking hard about the trends, where the technology is going from a hardware and a software perspective, and considering how to adapt and take advantage of it. That's what I recommend doing.

RJ: At Microsoft we have developers, program managers, and architects. People are often curious about the role of the architect. What's your expectation for the role of the architect on the team?

SG: There are a couple of responsibilities that we hope or expect an architect to bring to a team. One is a very deep, solid background in architecture, development, and the software principles I was talking about. With that type of background, our hope is that a process of osmosis will take place—that some of it will rub off on other team members. Hallway conversations or informal office chats can provide a tremendous amount of leadership to a team, especially when you supervise junior and senior developers.

We look for an architect to pave the way regarding what the product should be doing from a technical perspective. Often architects do more advanced prototyping work and investigations of where we should take the product. We look to them to recommend where we should go, and from an implementation perspective, we ask them to look at both the next-generation product and the current product to identify areas we should clean up. For example, which areas should we factor slightly differently? What are some practices we can implement throughout the code base to improve it?

RJ: In addition to deep, solid, technical skills, what other attributes do you think contribute to a successful architect?

SG: The hardest thing, at least at Microsoft, is that very deep technical people who want to go up the architect track need to make sure that they can marry their technical skills to an ability to work both within and across teams in a company.

Some of those softer skills are harder to build, meaning that an architect needs to be hands-on, but to do so in a way that doesn't threaten developers or other teams. They should also avoid "I own this, you own that" conversations. Architects have to be able to work across teams very flexibly. They need to do so in a way that doesn't leave people feeling as if the architect is just diving into the most interesting problem for the moment and then flying off when things get hard. Other team members have to believe that the architect is committed to the team and is part of a long-term relationship that provides value on a problem. Those are the types of skills an architect needs to develop. The super-senior architects who have the biggest impact can marry deep, deep technical and design skills with people skills and collaborative abilities.

RJ: A lot of people tell me is that the rate of change is accelerating and new stuff is coming out all the time. You mentioned how important it is to stay up-to-date on these things, but there are only so many hours in the day. How do you stay up-to-date?

SG: It's hard, especially in the development space. When I think of the pace of innovation that's going on right now and the rate of information flow, I certainly can't remember a time when it was going this fast. I think back to a time, the Internet battles of the '90s, when Internet Explorer was competing with Netscape. At the time, it felt as if we were shipping constantly, and there was a lot going on.

From the development perspective, I think we're in a phase right now where the pace is even more accelerated than it was then. It is certainly very hard to stay up-to-date. You have to find time to do it. You have to spend focused time keeping an eye on what is happening. I think blogs are a great mechanism for doing that. I subscribe to Bloglines, which is a great free service. I probably subscribe to 300 or 400 blogs, and I try to spend 20 to 30 minutes a day in the morning and the evening reading through what everyone posts. It gives you a good sense of what the hot topics and the interesting ideas are.

Part of keeping up means spending an hour a day of focused time doing prototyping; trying things out, either with your own product or other technologies; getting a good grasp on what pieces are out there and how you can use them. The other important task, when you're looking at any new technology, API, methodology, or programming approach, is to look hard not just at the interesting thing itself, but also try to extrapolate its useful principles so you can apply them elsewhere. So, if it's a Java refactoring book, great. There are some specific Java refactorings there, but what are the broader refactoring concepts you can internalize and apply to VB or C#? If it's an AJAX JavaScript framework that's very good at doing one specific task, great. Now, step back and try to recognize which of its aspects could be applied on another JavaScript framework. An architect should be good at looking at something and extrapolating the interesting aspect in and of itself, as opposed to the individual element of the technology.

RJ: As you look back over your years here at MS, is there anything you regret?

SG: As you look back, there are things you would do differently. Sometimes, it might be a technical thing you've done, the way you've implemented a feature, and you think, "Everyone abuses that feature." Or they do things not quite the way we intended them to be done. Certainly, when we've built a development platform as broad as .NET, I could come up with a dozen or so things that in hindsight that I wish we had done slightly differently. There are also ways that you approach things, or ways that you work with different teams and think, "Gosh, I wish I'd handled that conversation slightly differently." So, there are definitely lots of individual examples I could come up with.

Overall, I'm happy about where .NET is, so we've been fairly successful with where we've taken it. But there are lots of things I wish we'd done slightly differently, such as, "Gosh, I wish we hadn't sealed that class," or, "Gosh, I wish we hadn't unsealed that class."

If there's one significant thing I wish we'd done differently, it would be that we'd spent more time early on thinking hard about the client installation process for building .NET client apps. I think the approach we took with a single redistributable that you download is not any worse than any other Windows redistributable, but I wish we'd taken the opportunity early on to get a less impactful installation and simplify client-app deployment. That is something we're spending a lot of time on right now, and it's going to get dramatically better in the future, but I wish we'd done that six years ago and spent more time thinking through some of those scenarios a bit earlier.

RJ: In your office you have all these speaker badges going way back, and you've had chances to go many places and meet a lot of people. What highlights have you had? Is there anybody in particular that sticks out in your mind?

SG: One of the things that's fun about working on a developer platform is just seeing the range and diversity of apps people have built on our stuff. Whether it's MySpace, which is the largest social-networking platform in the world—there are a billion-and-a-half page views a day using .NET—or the London Stock Exchange or National Health Service of the U.K., or a whole bunch of companies on Wall Street, Costco, Dell.com, or Match.com, there are tons of cool customer apps built on Microsoft technology. Many of these are on the Web; others use different technology. If you go to the Walt Disney World properties, the meters that run the "Fast Pass tickets" run on the compact framework and the CLR. If someone knocks on the door from the U.S. Census or the U.S. Postal Service, the device that person is holding also runs on the .NET Framework.

That, for me, is the highlight: seeing how .NET is being used all over the place. Sometimes in weird, whacky ways, sometimes for mission-critical apps, but each time in a unique way that, frankly, you might not have thought of. I think the hallmark of a good framework doesn't lie in the applications people build on it that you had expected them to build, but in the fact that customers and developers were able to take it far beyond what you had imagined. For me, that's the highlight of .NET.

Scott Guthrie's Career at Microsoft

Scott Guthrie joined Microsoft in 1997 and first worked on IIS4 and the Windows NT Option Pack. Shortly after its release, he designed and prototyped a new server programming model originally codenamed "XSP," and together with Mark Anders subsequently formed and staffed a new team in 1998 to build what would ultimately be called ASP.NET.

Scott became production unit manager (PUM) of the ASP.NET team in early 2002, and shipped ASP.NET V1.1 as part of Windows Server 2003. During this time he also led the incubation of the popular Web Matrix development tool, a free ASP.NET development tool that helped spark new thinking about tools for Web development, as well as a new approach for targeting programming hobbyists and enthusiasts. In late 2002 he also became PUM of the Web tool features within Visual Studio and was responsible for the development of the new Visual Web Developer standalone product that will ship as part of the Visual Studio 2005 family, as well as all Web development features in Visual Studio. Visual Web Developer and ASP.NET 2.0 entered their first widespread public beta in the summer of 2004 and will ship in the first half of 2007.

In late 2003, Scott's team merged with the IIS team, and he became PUM of a unified Web Platform and Tools team that combines the assets of IIS, ASP.NET, and Visual Studio. Concurrent with finishing up ASP.NET 2.0 and Visual Web Developer, the team is now actively developing the next major version of Microsoft's Web Application Server, which will ship as part of Longhorn.

Now a general manager in Microsoft's Developer Division, Scott runs the development teams that build CLR, ASP.NET, WPF, "WPF/E," Windows Forms, IIS 7.0, Commerce Server, .NET Compact Framework, and the Visual Studio Web and Client Development Tools.

Scott graduated with a degree in computer science from Duke University in 1997.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.

© Microsoft Corporation. All rights reserved.