ARCast - Scott Guthrie - the man, the myth, the legend
Ron Jacobs: Whoa, booyah! Hey, what's up? It's time to start our 'cast. I'm trying hard to find something different to do, to get us out of our rut. Well, today we're going to do something a little different: I'm talking to Scott Guthrie.

He's one of the most interesting guys at Microsoft right now, one of the best conference speakers; he's deeply, deeply involved with ASP.net--you could call him one of the inventors of it.

We'll talk with him about his history at Microsoft, his career, a kind of getting-to-know-you interview, and excerpts of this interview will be used in the next Architect Journal.

And so, you can read it there, or you can listen to it here--because we've got Scott Guthrie, in his own words. So sit back and relax, for Scott Guthrie.

Hey, this is Ron Jacobs. I am back here in Redmond, where it's a cold and gloomy day today; I think it was one of the first cold days of the year, frost on the windshield and such, and I'm in the rather austere and small office of Scott Guthrie.
Scott Guthrie: Hey, good to be here.
Ron: You know, I kind of expected you to have the big, booming corner office with the secretary out in front... but you don't go for that, I guess?
Scott: Yeah, small and minimal is what I like. [laughs]
Ron: So we're going to talk about your experience and your career, because a lot of people listening are thinking, "Hey, that's a cool job." So let's start with that: What exactly do you do here at Microsoft?
Scott: I run our.NET developer platform group. So, that basically includes the con-language run-time, the.NET compact framework, IIS, ASP.net Atlas, commerce server, Windows Vista Presentation Server or Avalon, and then basically our developer tools for web apps, in Visual Studio, as well as client apps.
Ron: Wow, that's a lot of surface area.
Scott: Yeah, it's a lot of fun. It's kind of our core application models, both the core application tools and the engines they run on top of, so it's a lot of cool stuff to play with.
Ron: Most people will remember you from your association with ASP.net over the years; that's kind of been your sweet spot. So, going back to your early days at Microsoft, how did you get started here?
Scott: I started with the IIS team way back in '96, '97, and basically it was working on our core web server technologies. We shipped a version of IIS back then. And then after peeling off IIS 4, we started working on next-generation web programming.
Scott: At the time, it was kind of funny; we looked back and said, "Are we done? Is there anything more to add, in terms of feature set?" And we looked at the state of the web today.

At the time, ASP and MTS and MSNQ were kind of the cutting-edge; they'd just shipped. And there were a lot of people who questioned, how many more features are there left to do? Have we done everything?

We started talking with a lot of customers, looking hard at the kind of apps they were doing, and we quickly learned that there was a heck of a lot to do.

And we looked at the common patterns, over and over again, that people were struggling with, in terms of code-content separation, writing clean code, there were a lot of people who joked, "Write once, read never"--that was the kind of code being produced.

And in terms of the tooling and run-time administration perspective, just tons of challenges for making our infrastructure work really well.

So we started a team that came out with our future HV.sys kernel driver that shipped with Windows Server 2003, and I kind of, with a colleague of mine, started looking at web programming pieces, and I wrote the initial prototype for what became ASP.net.
Ron: Wow. It's funny that you say that people were like, "We've done it all, we don't need it anymore." But there are always people with that kind of "hey, it's good enough, we don't need anymore" mindset.

You were really taking it to the next level and taking advantage of a thing that was super-secret at the time; I remember those days of.NET. You used to call it ASP+ way back then.
Scott: Yeah, we originally called it XSP, and people asked, "What does the X stand for?" And at the time it didn't really stand for anything; it's just that XML was out, XSLT was out, it's just originally how we named it.

And for the first six months, we actually didn't use.NET. The CLR, the Common Language Runtime, that didn't really exist yet. So, we did most of our prototyping in C++ and JavaScript and Active Script script engines, which were a nightmare, and in Java.

We kind of knew we wanted an object-oriented environment, and we really liked some of the characteristics that a managed programming model provided, in terms of garbage collection and encapsulation and these nice object-oriented techniques.

And we actually started writing our prototype code in C++, though, because at the time we didn't really have a good run-time platform to build on top of.

We were two weeks into it when we met up with the Common Language Runtime team, which had no partners inside of the company building on top of them. The only compiler they had at the time was this thing called Simple Managed C, which we affectionately called SMAC.

[laughter]

We ended up deciding, you know, maybe we should build on this. And it was a huge risk. At the time, our team was 3-4 people, total, so we were kind of allowed to take a bet on it mainly because no one cared if we failed. And thankfully, we succeeded, it took off, and the rest is history.
Ron: You know, I remember in the early days of the CLR, there were a lot of people who weren't willing to take that bet. But you did, and it paid off in a wonderful way.
Scott: Yeah, it was, the whole idea of garbage collection on the server, which we take for granted today, just terrified people at the time: "There's no way you can build a real app running in the background! Your server will never scale!" There were lots of nightmare scenarios.

And we decided, we're going to embed our management code, and we're not just going to have managed code as a wrapper around the native stuff; we're going to really bake it in, put it in 95% of our code.
Scott: The reasons for that were two-fold: One was the flexibility it provided, to really bake in object-oriented sensibility very deeply.

The other reason is, we basically said that at the end of the day, customer apps are going to be written in managed code, and the percentage of code on the stack that's ours versus the customer's is going to be relatively small.

So if we don't even think we can write ourselves in manager's code, then we're kidding ourselves that we think customers apps are going to sail.

So it was a great forcing function where form day one when we provoked my solo world...

Then more complicated samples, you know we were tuning kind of the core CLR engine along the way. That translated into huge customer savings and we started getting more complicated apps on top.

It was a good bet.
Ron: Yeah, yeah. No kidding. Well it's interesting that you look at this as a way to drive improvement down into the engine.

You're saying not only are we going to bet on this, but we're going to make the engine better by doing so.
Scott: Yeah. I think that was a huge bet, or an approach to take that really worked out well. The fact we were a small team and we were starting with a new code base helped tremendously.

I think if we were a larger team and/or we had an existing large legacy code base, that bet would have been harder to make. But the fact that...

Because back then there wasn't even Com inner-op. But the fact that we were starting kind of from scratch and we were able to start small really helped in terms of driving those core improvements deep into the engine.

As we got bigger and as our feature set kind of flushed itself out, it just kept paying dividends along the way which was just great.
Ron: I think it's cool that the people who were managing you guys at the time gave you this ability to make that call.

You know a lot of people are kind of risk adverse. You know, no don't go do that. Let's go with the safe thing.

They said no, we're going to bet on this and go for it.
Scott: Yeah it was definitely a gamble, but it was a calculated gamble. We said you know the upside would be huge if we can make this work.

The downside, you know it's three or four of us and you know...We'll try to do something new the next year if it didn't work.

I think Microsoft often makes these sorts of big bets, and usually they can pay off in a big way. You know occasionally we have...

You know if they don't, they can fail spectacularly. That is something as a company that we do try to make sure we bet big on a couple of key things and it pays off in a big way.
Ron: So did you have to try and persuade anybody to let you go with that, or was it easier than that?
Scott: We certainly had to persuade a number of people along the way. One of the thins we did king of early on in the project was try and get running code into prototypes that we could actually show people.

I think often times when you're working on a project that is new, or something that hasn't been done before it's often very difficult...

You know it's easy to put together a bunch of PowerPoint slides that sound good, but its super valuable to actually show code, and to actually get code running that you can walk through.

Both because it proves to yourself that it's real, but also I've found that you just learn a tremendous amount by doing it. So it's one of the things I always try and do with me teams.

You know, prototype early, build sample apps early, and effectively build demo apps. You know at the end of the day we want to be able to walk a customer through and say look, here's how to build an app.

How can you do that as early as possible in the process?

So you can learn what works and frankly what doesn't work, and you can react accordingly. About a month and a half into the API project, I basically wrote this prototype and we were able to walk people through it.

You know, here's this component, control-driven model. We didn't call them controls back them; they were kind of declared tags or components.

So here's kind of this event-driven way of programming the web. We were able to build apps, and we discovered quickly that some of the things that we came up with were really impossibly difficult to code when you started writing the real apps.

At the same time we kind of learned oh you know what it'd be really cool to have this feature or that feature. We kind of iterated it along the way and that helped tremendously also when we were trying to get people to realize that we weren't complete lunatics making a bet.

We were able to show code and they were able to say OK, I get it.

It's still a gamble but much further along in understanding what you're trying to do, go for it.
Ron: You know it almost sounds like the test-driven development kind of mindset.

Let's do short iterations, let's get to something that works, we'll eat our own dog food so to speak. We're writing against our own API's to understand what it feels like to use them, the same kind of principles.
Scott: It's definitely the same kind of principle. I kind of differentiate a little bit in terms of test-driven development as kind of a methodology for how do you drive quality early.

And how can you basically provide a base that allows you to re-factor and adapt your code base without having to worry about regressions.

I think that's...We certainly follow that philosophy internally when we're developing production code. I think there's also sometimes value in doing kind of a prototype phase even before you get to production code.

That's one of the things that we did with ASP net that I thought was successful. Where we sort of said every line of code we're going to write for the next couple of months we're going to throw away.

You know, 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 Del tree the subdirectory at some point.
Ron: [laughter]
Scott: That way we can actually be a little bit more adventurous in terms of trying new things out.

We also don't have to necessarily worry about everything being robust and being something we're going to take forward.

So we actually did that for a couple of months then we reached a point where we said OK we're done, delete it. Let's start over from scratch and now let's actually write the full production code.

Let's make sure we bake in quality at the time. I think a lot of teams could benefit from that...Like the hardest thing is making sure you delete the prototype code.
Ron: [laughter]
Scott: Too often I kind projects kind of grow up where you say well you know it's kind of close.

You know and it's very difficult to start with a prototype and actually make it robust. But you know I'm a firm believe in that kind of prototype experiment phase and then delete it.
Ron: You know what I like about that is that it shows...

You know you're saying look we value the learning more than we value these files and these bits that we've built during the prototype phase.

That's irrelevant. Let's focus on the lessons we learned so that we can do it right the second time when we get out and do it.
Scott: Yeah and I think every time you work on a project, if you rewrite anything...Whether it's from scratch or not the code gets better.

Part of it's because you understand the problems and the pitfalls of the last approach. Then you're able to kind of reflect on it and do it better.

You know the challenge is that you can't easily do that time and time again. But I think when you're first starting out on a project or...

Especially a brand new area where the path isn't clear for how you get from point A to the finished product.

Having a dedicated set of time that you spend prototyping and kind of experimenting and trying stuff out is super valuable.
Ron: Yeah and some people call that the architectural spike. It's like here's a new area we're going to explore it. I love that.

But now...Before you came to Microsoft what were you doing?
Scott: I actually joined Microsoft straight out of college.
Ron: Oh, OK.
Scott: So I interned at Microsoft while I was in college and I was involved in a couple start-ups during college, high school, and things like that. I did some development and had some fun there.

But yeah I actually joined straight out of college, Microsoft Campus Hire.
Ron: Wow, wow. Yeah, and what school?
Scott: I went to Duke.
Ron: Duke OK wow. So the good old Blue Devils down there and all that...
Scott: Yeah exactly.

[laughter]
Ron: Yeah, all right!

[laughter]

See I know my sports memorabilia here, OK, so if you...

We're talking to a lot of people who find architecture kind of interesting. People who listen to our casts, I think many of them are developers.

I find actually that there are very few people who are purely architects. I mean that they only design stuff and they never write code.

I mean most people are some kind of a mix. They spend some time developing, some time architecting what kind of advice though do you give to people that's somebody's who's been maybe learning development, but wants to do more architectural thinking?
Scott: Well I think writing code is valuable for an architect.

Not necessarily production code that you check in, but constantly be trying new technologies out, new approaches out, and kind of feeling how does the system work I don't quite frankly write a lot of production code these days.

Really, any, but I'm always spending usually an hour or two a day writing code.

Whether it's samples, whether it's prototypes that I pass on to people, or whether it's just you know some fun personal project. You know, trying things out, kind of thinking about ways to kind of structure things.

I think being that kind of hands on is very valuable in a code-architect kind of perspective.

The other thing from an architect perspective that I...I'd really recommend doing is looking hard at core systems theory and looking at you know...

How do you architect very robust systems and what are some of the principles that you want to think about and apply as you're doing it?

That doesn't mean kind of what the lines of code look like, but in terms of thinking about simplicity, or thinking about robustness, or thinking about fault tolerance.

You know those types of things regardless of where the squirrelly brackets go or you know how you factor it. These are core things I think in very successful systems, whether it's a client Apple, it's a server Apple, or it's a game.

You know as an architect, thinking hard about those types of principals if you can merry that with a good coding background, you can really help provide a tremendous amount of guidance to teams.

So you know, some of those things isn't doing it with the wizard, or isn't necessarily even checking out the cool new stuff. But it's studying you know, how does the process of dress space work in a Windows, or UNIX application?

You know, what exactly is threading and how do you deeply internalize what it looks like on a multiprocessor, or multi-core system?

Taking that type of knowledge in and thinking about its ramifications, and then spending some focus time really thinking hard about where the trends are going, where the technology is going from a hardware perspective.

Then from a software perspective, how do you adapt and take advantage of it? That's something I'd definitely recommend doing.
Ron: So you oversee a lot of teams as we mentioned earlier. At Microsoft we have developers, program managers, and we also have architects.

Many times people are curious about the role of the architect. So when you look at these teams, what is your expectation for the role of the architect and the team?
Scott: Yeah I kind of...

There are a couple of roles, or a couple of responsibilities that I think we look at from an architect perspective that we kind of hope or expect an architect brings to a team.

I think one is kind of a very deep solid background in architecture, development, and going back to sort of those software principles that I was talking about.

You know, that type of background. They can more than necessarily work on a specific task. Being on the team and being around people on the team you know...

Our hope is... You know there's a process of osmosis. Some of that rubs off, and just in hall way conversations or just sort of informal office chats, they can provide a tremendous amount of leadership and experience to a team.

Especially when you have a mixture of junior and senior developers.

Then I think specifically from a task perspective, the things that we look for architects to provide are both to kind of pave the way in terms of what should the product be doing from a technical perspective?

Often they do some more advanced prototyping work and investigations in terms of where we should take the product. So we'll look to them to prototype V next, or to prototype an area of V next out.

You know, kind of come up with prototypes and recommendations as to where we should go. Also from an implementation perspective, have them delve deep into the product and look at both the next generation product, but also the current product.

You try and identify where the areas that we should clean up, or where are areas that we should factor slightly differently?

From an implementation perspective going forward, what are some best practices that we can implement throughout the code base to make it better?
Ron: So we all expect that an architect is going to have deep, solid technical skills, but I'm curious what other kind of skills you think contribute to a successful architect?
Scott: I think the hardest thing for a lot of architects, at least at Microsoft is you sometimes have very deep technical people that want to go up the architect track.

You need to make sure from an architect perspective that you merry your technical skills with the ability to actually work across teams. Both within teams as well as across different teams with a new company.

I think some of those softer skills are sometimes ones that aren't you know...Sometimes harder to build.

Meaning you need to be able to be very hands on in a space. But do so in a way that doesn't threaten developers, or other teams that are working in it.

You want to avoid the whole I own this, you own this kind of aspect. You've got to figure out how to work across teams very flexibly.

You also need to do so in a way that people feel like, you know you're not always necessarily just diving into the most interesting problem, or shiny object or the moment and then fly off when it gets hard.

That you're committed on the team and there's kind of a long-term relationship where you're able to provide value on a problem.

So you know I think those types of skills an architect needs to make sure they kind of develop. The super senior architects that have the biggest impact...

I think they merry deep technical and design skills with the software people, and collaboration aspects.
Ron: Ah, OK.

Now one of the other things that a lot of people tell me is it just feels like the rate of change is just accelerating. New stuff's coming out all the time, you're heads spinning around.

You hear about this standard, that technology going on. You were talking about how important it is to stay up to date on these things, but I mean there are only so many hours in the day.

I mean, how do you do that? How do you stay up to date?
Scott: It's hard. I think especially in the development space...

I think the pace of innovation that's going on right now, and just the pace of information flow...

Certainly I can't remember a time ever when it was going as fast. I think back to the Internet battles of the 90's, where you know how it was part of the sort of IS/IE.

You know, the competing with Netscape kind of phase. You know at that it time felt like we were shipping constantly and there was lots of things going on.

But, I think from a development perspective, I think we're in a phase right now where the pace is perhaps even more accelerated than it was then.

So that certainly it's very hard to stay up to date. I think part of it is you have to find time to do it. You need to make sure you spend some focus time keeping an eye on what things are happening.

I think blogs are a great mechanism for doing that, so you know I subscribe to Bloglines which is a great free service that you can use to. I probably subscribe to 300-400 blogs. You know I try to spend 20-30 minutes a day in the morning, and usually 20-30 minutes in the evening.

Basically just reading through what everyone posts and it gives you a good sense of what the hot topics are, what are interesting ideas, what are interesting things to try out.

I think part of it is spending ideally an hour a day where you spend focus time doing prototyping. You know trying new things out either with your own product or with other technologies that are out there.

Just getting a good grasp of what all the different pieces out there are and how you can use them. I think another thing is that when you're looking at any particular technology or you look at any new API, or any new kind of methodology or approach is to look hard at not just the thing.

You know, for the individual thing's sake. Actually try to extrapolate the interesting principles from it that you can apply elsewhere. So if it's a Java refactoring book, great. There are some specific Java refactoring you can use there but what's the broader kind of refactoring concepts that you can internalize and apply to VB or C sharp.

If it's an Ajax JavaScript framework that someone's written that's very good at doing one specific thing, great. Play with that and then step back and internalize what the interesting things are that it's doing that I can apply over here with this other JavaScript framework.

I think an architect needs to be good at looking at something and kind of extrapolating what the interesting aspects are in itself as opposed to just the individual technology.
Ron: So as you look back over your years here at Microsoft, anything you regret?
Scott: It's...I think there's...I think the hard thing is...
Ron: [laughter]

You've had such an amazing career it's hard to pick one bad thing right?

[laughter]
Scott: [laughter]

I think as you look back, I think there are things that you do differently. Sometimes there might be a technical thing that you've done where you look at the way you implemented a feature and you kind of go ah, everyone's abusing that feature or they're doing things not quite how we intended.

So certainly when you're developer platform as broad as.NET, I'm sure I can come up with a dozen or so things that I wish in hindsight that we'd done slightly differently.

I think there's also ways that you approach things, or ways that you work with different teams where you go hum...Gosh I wish I handled that conversation slightly differently and so...

There are definitely lots of individual examples I could probably come up with. Overall I think I'm pretty happy with where.NET is and so I think overall we've been fairly successful in where we've taken it.

But yeah there's lots of individual things that I wish we'd done slightly differently, or gosh I wish I hadn't sealed that class or gosh I wish we hadn't unsealed that class.
Ron: [laughter]
Scott: You know there are lots of examples I can come up with there.

[laughter]

But you know I think there's one thing that I wish we'd done differently that's kind of more significant is I wish we'd spent more time early on thinking hard about the client install process for building.NET clients.

I think the approach we took with kind of a single redist that you download is not any worse than any other Windows redist., but I think we probably had an opportunity early on to actually think hard about ways that we could make it a more non-impactful install and simplify client app. deployment.

That's where we're spending a lot of time right now doing so that'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 little bit earlier.

But you know, we're getting there.
Ron: OK, all right. So on the other side; you've had a chance to travel a lot. You have on your board all these speaker badges going way back. You probably have more than I do.

[laughter]
Scott: [laughter]
Ron: I see one from 99' there, wow that goes way back.
Scott: [laughter]
Ron: So you've had a chance to go a lot of places and meet a lot of people. What highlights; anybody in particular that sticks out in your mind?
Scott: Well that's one of the things that are fun about working on a developer platform is the range and diversity of apps. that people have built on our stuff.

So whether it's MySpace which is I guess the largest social networking site in the world; there's like a billion and a half page views a day using.NET to...The London Stock Exchange or the National Health Service in the UK. Or a whole bunch of companies on Wall Street; Costco, Dell.com, Match.com, you know there's tons of cool customer apps. that are built from our technology.

Both on the web, and then you know...If you go to the Walt Disney World properties and you get a ticket and you ever put it in one of the meters or ask someone for help with one of those fast pass tickets. You know that's running these in the compact framework using the CLR.

If you go and ever get...If someone knocks on the door and it's the US Census or the US Postal Service, well, they're also using.NET as a client app.

That for me is the highlight is sort of seeing how.NET is being used all over the place. Sometimes in weird whacky ways, sometimes for mission critical lapse, but each time in a cool unique way that frankly we might not have thought of.

Ultimately I think the hallmark of a good platform is not the apps that people built that you were expecting them to build, but that you enable a platform where customers and developers are able to take it far beyond what you imagined.

That for me is the highlight of.NET.

[music]
Ron: Oh, nice. Well thanks so much for sharing with me today.
Scott: Cool. Thanks for having me.
Ron: Scott Guthrie ladies and gentleman.
Audience: [clapping]
Ron: Isn't that fun you know, get the whole history behind how all this stuff worked behind the scenes and the history behind the secret XSP and ASP plus.

I love thinking about the ways in which we learned to build this stuff and hearing about it is interesting history right?

But hey I am interested in hearing from you. In fact we have just started a new thing. The ARCast listener's survey and you can go to ARCastSurvey.net and tell me what you think.

I've posted it on my blog already and had a number of people fill it out but I want you to go and tell me what you think about ARCast because we want to make the show better. We want to listen to you. If you want, send me an email. Send it to ARCast@Microsoft.com.