In this interview, Scott Swigart, interviewed Shawn Burke of Microsoft. Shawn Burke regarding the way software is developed within Microsoft. Shawn is a Director in Microsoft’s .NET Developer Platform group. Currently, Shawn is focused on building shared-source projects focused on new developer technologies from Developer Division. Since he started working at Microsoft in 1997, he’s worked on Visual J++, Windows Forms, and Visual Studio.
This interview covered a wide range of topics some of which follow:
- Eating your own Dogfood at Microsoft
- Product Idea Triage at Microsoft
- The difference between Product Milestones, CTP’s, and RC’s at Microsoft
- Closed Source Cores with Open Source Add-On’s
- Extensibility and Software Development
- Security, Reliability, Scalability and other “ities”…
Scott Swigart: Shawn, thanks for taking the time to chat with us. If you wouldn’t mind, could you introduce yourself a little bit?
Shawn Burke: My name is Shawn Burke. I’ve been at Microsoft going on 10 years now. I’ve spent most of my career at Microsoft on the Windows Forms team. Originally it was the WFC team, which was part of the Visual J++ product. On Windows Forms (which became a big chunk of the .NET framework) I went from just a software engineer to lead engineer up to development manager on that product. I ran that team for three or four years. When VS 2005 shipped in 2005, I was ready for a change. I saw what I thought was a bunch of opportunities for Microsoft to improve the way that we develop our software, specifically around driving good contextual feedback into our products at an earlier point in the development cycle.
I went to Scott Guthrie and said, “Hey, why don’t we create a team that’s fully focused on consuming early technologies here at Microsoft.” We’re going to expose our learning (and what we’re doing) really transparently out to the community. We’re trying to drive a tight feedback loop from the community into the development team who is actually building the product. We’re trying to improve quality all along the axis.
Shawn: Kind of, yeah. The dog food thing is usually more at a consumer-level. We’re really focused on development technologies. We’re focused on, “Hey, some technologies are just getting off the ground. What can we go out and try to build on top of that technology and really drive scenarios?” Can we take actual Microsoft plugged-in engineers and do things with technology and influence how it develops? It’s an extension of the dog-food-eating thing, but it’s a little deeper than that.
Scott: That makes sense. My background is also with developer technologies, and I’ve noticed regardless of whose technology you’re using, that you sit back and look at it and wonder if the company that built it ever tried to do anything “real” with it. There are always a lot of things you stub your toe on when you start.
Shawn: There’s one problem with developer technologies though, and this is something people don’t really often realize. When I build Minesweeper or Notepad or an application like that, it’s very easy for me to enumerate the scenarios that people are going to use on it. If I build a compiler or a framework, it’s very difficult to enumerate the scenarios. There are essentially an infinite number of them. The stubbing-the-toe phenomenon is one we definitely focus on, and one of my goals is to try to avoid that. At the end of the day, it’s really hard to know exactly what people are going to use the development tools and frameworks for.
Scott: Talk to me a little at a really high level about how Microsoft builds software? Where do ideas come from, and how do these get slated for coding? How do they get built? What are some of the things along the process to release and then even to servicing?
Shawn: So traditionally what’s happened is that’s been driven simultaneously bottom-up and top-down. What’s usually happened is that you have teams that have released a prior version of a product. They’ve learned about the space. They looked at the industry. They realize a need by talking to customers in a variety of ways. They start coming up with things they think are going to address the needs of their customer set. They do that via their engineers working with customers across their prior project. They do that via their engineers just having brainstorms about, “Oh my gosh. We could solve this problem this way,” et cetera.
So what ends up happening is that you wind up with a bunch of product ideas early in the product cycle, and people start slating out things that they want to do. We’ve gotten more regimented about this. In the past, it was more like we’d just write everything down that we wanted to do, and we’d start going and doing it. Then, farther down the road, we’d have to start cutting things.
We’ve gotten better about that. We have quite a bit more top-down influence now. Not over specific features, but what ends up happening is that the feature teams have a good read on what they think they need to do. What happens top-down is that we have what are called “pillars” for a given product.
For Visual Studio 2005 one pillar was “Please the VB [Visual Basic] customer.” The VB customer (from the old Visual Basic days) was not terribly thrilled with our VS 2003 and 2002 releases. It didn’t really address their needs in a way that we thought it was going to. For 2005, one of the pillars was to address the needs of the VB customer.
From the top-down we’ll have a few pillars, and the individual teams will need to justify how each one of their features fits into one of those pillars. At that point, there tends to be some agreement on what people go off and build.
The process varies from team-to-team and from division-to-division within Microsoft. In the developer division, the developers and the program managers will sit down and spec out a feature. PMs will write the specs, and the developers will give them technical input. The developers may write prototype, since the best way for most people to learn about a feature is to try and write it.
Then it becomes an iterative process where you refine the specs as you start to develop the product. As time goes on, resource constraints usually cause you to trim down what you’re going to deliver. You just iterate from there.
Scott: So software a lot of times goes through different milestones, you’ll hear about a product being an M1 or an M2.
Scott: There are CTPs and there are RCs. What is all that? What’s a layman’s glossary?
Shawn: Usually what happens is similar to Boyle’s Law: work expands to fit the space you give it, much like a gas. So you need to put constraints in there to get things to ship.
One of the ideas of milestones is to force teams to think about their products and their features in manageable chunks. The risk of having somebody go off and crank on a feature unsupervised for months or years at a time means you’re going to have issues. That just doesn’t work. So what you do with milestones is force people to break things into manageable chunks. You make them tightly figure out exactly what the costs are going to be, figure out exactly what the testing recommendations and requirements are going to be, etc.
Usually what happens is that teams take their features for an entire product and break them up into milestones: milestone one (M1) we are going to do this feature, milestone two (M2) we are going to do this feature, etc. At the end of each milestone, you have a mini-release. A lot of times you do Community Tech Preview (CTP) at the end of a milestone. Usually at the end of a milestone your at a know point where, which is to say the product is at zero active bugs at a certain priority level. You figure out some filter for your bugs, and you say we’re going to drive to zero at the end of the milestone. Then you start over again with the next milestone.
As milestones go on, you are more and more careful about adding features. Milestones are also used between teams. If team A needs a feature from team B, team B will do that as an earlier milestone so that team A can pick it up sooner.
Another thing we started to do is add something that we call milestone quality, MQ. Some people also call it M-crit, which is essentially a special milestone where we don’t actually want teams writing code. What we want them to do is make sure their processes work properly. We want them to make sure they’ve cleaned up any bugs that are left over from the prior product cycle, or bugs that have come in after the release of the product, time to improve check-in systems, things like that.
We’ve added this so teams get to focus on their infrastructure, which is a good thing because historically it hasn’t been on the schedule. It’s the old adage where a guy is walking down the path and sees two other guys trying to cut down a tree, and he says to them, “You know guys, that tree would get cut down a lot faster if you would just sharpen that saw you’ve got.” and the guys reply, “We don’t have time to sharpen this saw, we’ve got to get this tree cut down.”
So giving teams a time to really sharpen the saw and improve their efficiency is a good thing. That’s what usually happens in MQ. After that you usually have M0 which is the formal product scheduling and planning milestone and then you roll into the coding milestones – M1, M2 – from there. After that you usually have the Beta and RTM milestones.
Scott: We’re looking at open source and closed source, and Microsoft has obviously decided that a closed source way of doing business makes sense. What’s your impression of why that is? What’s your impression of why Microsoft doesn’t just open source everything?
Shawn: Well there’s a whole set of reasons. This project that I’m running now is an open source project. We’re building on top of the new technologies, and the things we build are actually open source. We are actually doing both. We take customer contributions, the whole bit.
What’s ending up happening, what is starting to evolve, specifically with my team (and we are looking at duplicating the model) is making a hybrid model where you have closed source cores, and open source projects focusing on added customer value, extended components, widgets, and stuff like that. As far as why Microsoft doesn’t go open source, there’s a whole set of reasons for that. I think the number one reason is just around IP pedigree. The issue with open source is that it’s very, very difficult–well it’s impossible–to verify with a hundred percent certainty that every piece of idea in there is licensed properly to be in there.
It’s very difficult for me to know if some developer that contributed to my project saw some code in some other project that he liked, and he picked that code up and dropped it into the project and maybe just tweaked it a little bit.
. “When your organization picks up software, you are taking on some amount of risk that there could be an IP issue with that code. That’s the number one issue that we see with open source. You don’t know how much risk there is, and there is limited, if any, IP protection provided. When people adopt Windows they are provided with