Interview with Blaine Wastell and Glenn Block – Patterns and Practices

Interview with Blaine Wastell and Glenn Block – Patterns and Practices – Microsoft

Interviewers: Scott Swigart and Sean Campbell.

Interviewees:Blaine Wastell and Glenn Block.

In this interview with Blaine Wastell and Glenn Block of the Patterns and Practices Group at Microsoft we asked them about:

Blaine: I’m Blaine Wastell. I’m a program manager in patterns & practices, and I’ve been in this role for a little over four years now. Most recently my focus has been in what we call the "client UX program". It’s about providing guidance to customers on developing both smart client and web client applications.

For 12 years before Microsoft I was out in the consulting world helping business customers develop enterprise line of business applications, mainly Web applications.

Glenn Block: I’m Glenn Block. I’m a technical product planner in patterns & practices. I am a newcomer to the client team. I’ve been in p & p for about 6 months, and with Microsoft for about 2 years. Prior to p & p, I worked in Microsoft Learning and was responsible for building online developer training.

For the 10 years prior to Microsoft I was a software engineer and architect. I worked in various startups as well as a few enterprises. I’ve had a touch of consulting, but it’s mostly been really about building both packaged apps and internal apps ‑‑ both on Web and on Windows. A significant part of my background has been in developing software frameworks for those kinds of applications.

And as the technical product planner on the client team, I’m responsible for the overall strategy, understanding what customers want, and setting expectations on what kind of guidance we’re going to deliver.

Scott: Talk a little about patterns & practices.

Blaine: We provide "building blocks" that customers use for line of business application. Microsoft has a number of development tools and technologies which include the .NET framework, Visual Studio, SQL Server, the core operating system, etc. We help customers by providing guidance, in multiple forms, on using those technologies to build line of business applications.

Glenn: The practices part of our name is focused on the latter, where we give guidance, best practices, and design patterns, to educate developers on known solutions so they’re not reinventing the wheel.

Scott: I’ve used like the Enterprise Library that patterns & practices produced, and it’s really more of a framework than building blocks. Are things like the Enterprise Library are designed to be best‑practice reference architectures, or are they drop-in frameworks designed to give a productivity boost?

Blaine: Enterprise Library, and the application blocks, are part of what we deliver. We also have written guidance for areas like security and performance.

We also have another type of deliverable called "software factories" that tie all the pieces together. They have the framework, but they also include the common patterns for a specific area. They include automation; they include what we call a "reference implementation" ‑‑ essentially a sample of how to implement proven practices using the frameworks.

Glenn: When you talk about frameworks, at the end of the day, to us it’s all guidance. In the case of these frameworks, they are incarnations of the patterns we recommed. We think of them as an 80% solution meaning they may not provide all the answers. We write the code with the intention that people who are consuming these deliverable will rip that code up, and will look at how we’re doing stuff. It’s not simply about giving people a reusable toolkit, although there is an aspect of that.

The idea is, "Hey, look at what we’ve done. Rip out the pieces that you think are applicable for your scenario. If you’re writing something new, you can use this as a reference point and know that it incorporates well‑known patterns."

Scott: What makes your team different from a Microsoft product team. How are you different from the teams building the .NET Framework, or SQL Server, for example.

Blaine: We focus on what we call ‘customer connected engineering’. We start with an area that we see is challenging for customers, and then we will put together an advisory board that includes customers. As we design a solution, they’ll validate that our scope and approach is really hitting the top set of challenges that they have.

Glenn: The big differentiator is that product groups build the platform, while the guidance we create uses the platform.

Product teams focus on taking the platform to the next level. We do guidance, as Blaine described, guidance on using the platform. We show you how to put the legos together in meaningful ways to solve particular problems that you’re facing.

In some cases, through the act of putting those things together, we may pull out some new reusable guidance that we call ‘application blocks’. But the block is not the end goal. The block is just one incarnation of the guidance. When I say ‘block’ , I’m really referring to a reusable library.

Scott: Could you list some of the things that you’ve produced?

Blaine: You mentioned the Enterprise Library, which has a number of blocks within it. There’s also the composite UI application block, which is a library that helps you create smart clients. There is also a set of libraries to help you create web clients. One is called the composite web application block. And we also have another one called the pageflow application block which addresses challenges around Page navigation. Blaine: We’ve done a number of things in the web services area.

Glenn: We have a Web service software factory; which is guidance on building web services. And we also have new guidance that we’re developing called ESB guidance which addresses utilizing BizTalk as an Enterprise Service Bus.

Scott: Talk a little bit about the software development methodologies that you use.

Blaine: Sure. We are an agile organization. We’re probably closer to XP. We start with the backlog that we prioritize. Glenn is essentially the proxy for the customer; the one that will prioritize the backlog for us. From that we do the standard iteration planning, and meetings. We do it once a week, and we have stand ups daily where we go through the status of the standard set of questions: What did we do yesterday, what do I plan on doing today, what blocking issues do I have.

At the end of an iteration, which is every week, we publish our results out on our CodePlex community site. Then customers can look at the CodePlex site and get an understanding of where we’re going. A lot of times they’ll say, "Hey, why are you doing this, because I have these other two sets of challenges you’re not covering," which is good. We’ll also have people say, "Hmmm. There’s a bug in line 35." It’s pretty amazing how closely customers sometimes watch us.

Glenn: And in some cases even supply fixes.

Blaine: Right. We’ll also do testing, development, and continuous integration. We use in test driven development, so we write the unit tests first, and then the code.

We’ll generally do pair programming. We’re also distributed team with team members located in Redmond, Buenos Aires and India. This sometimes makes it hard to always do pair programming. If we can’t do pair programming we will have somebody else do a code review before checking the code in. We do automated exception tests where they make sense. We do quite a bit of static analysis on the code that gets checked in.

Glenn: How about code coverage?

Blaine: We do code coverage. I have a blog entry that I just put out recently that talk about the quality checkpoints that we go through. On the quality assurance side, we’ll do things like proof and security testing, and globalization testing.

Scott: You mentioned there’s also a community side of what you do. Talk a little about that.

Glenn: There’s several different ways that we actually interact with the community and our customers. The simplest way is our blogs. A good portion of the team is heavily into blogging, and we try to give as much visibility as possible into what we’re up to.

Blaine mentioned that all of our stuff is on CodePlex. A big differentiator between the work that we do, and the product groups at Microsoft, is that you can get all the source code.

Also on CodePlex we have work item voting. When people come to us with feedback we say, "Great idea. Throw that on as a work item so the rest of the community can vote." And I can tell those work items absolutely determine what we do.

For example, AJAX support in the Web Client was one of the highest voted work items. As a result we’ve done about four months of work on the UI responsiveness and we have a few more to go. That’s a large investment and it’s based off the community feedback.

In some cases, there’s a work item that’s very broad, and we’ll dig in. For AJAX there’s a server side and client side aspect. When we asked which people were more interested in us investing in, people said, "Hey, we’re more interested in the server than in the client."

Another source is our direct interaction with customers. One of the things we do in p & p is bring a lot of customers in to spend time with the team. That gives us an amazing opportunity to directly interact with them, find out what they’re building, find out how our guidance in mapping against their needs, and find out what the gaps are.

We just had a customer that was here for an entire week. We do that with a number of clients and aggregate the information and learning which we inject back into our efforts.

We also do some on‑site, where we go and visit customers. Since I’ve joined, I’ve visited two customers ‑‑ one in the U.S. and one in the U.K. ‑‑ spending a week with their teams.

Further, we have general blog that generates feedback that we get. We have email feedback that we get. That covers the external customers. But p &amp p also has internal customers. Who are those? These are the product groups.

Lately we’ve been we’ve been working very heavily with Scott Guthrie’s org. We’re doing this is because we want to understand what kinds of challenges the platform is going to be addressing and how it will be addressing itWe want sure that whatever guidance we’re giving is in line with this direction and not opposed to it.

And we also key in to their demand for deep content. They say, "Hey, there’s nobody who’s really telling people how to put these pieces together." We’re also getting very involved with OBA [Office Business Applications]. We’ve had the OBA team coming to us saying, "Look, we need some solid guidance that will give customers architectural guidance on how to develop an OBA application."

Sometimes all these inputs are in conflict with each other and we have to look at the external feedback, the internal feedback, the industry trends, open source, and even our competitors, and decide what we’re going to deliver.

Finally we have our Customer Advisory Boards. This is a key aspect of our customer‑connected engineering strategy. For every one of our deliverables, we have an advisory board of individuals that are in the industry, that are or will be using this guidance. For the Web Client Software Factory, every two weeks for about the past four months, we have an hour meeting where we present to the advisory board what we’re doing, and we get their feedback.

The advisory board is a group that’s able to look at what we’re doing and raise flags and tell us, "Hey, you’re going in the wrong way." Or they may be saying, "You guys are missing this big opportunity over here that really affects all of us." And when we build this advisory board, we select a group of experts across the industry in both small and large companies, some located in the U.S., some located in Europe, some located in Australia. We try to get a really good mix.

They have different needs. They give us a proper perspective on the overall landscape so that we can make those intelligent decisions. I think that covers it. As you can imagine, it’s not an easy task to drill through all of that input and decide which way to go.

Scott: Right now, the patterns & practices code is released under a custom license. It’s not under the Microsoft Reference license or the Microsoft Public License — which used to be the Microsoft Permissive License.

Blaine: Everything is migrating to the MSPL.

Glenn: Yeah. It’s essentially been MSPL without the name. It is going to be MSPL.

Scott: OK, so the MS Public License.

Scott: The thing that’s really interesting that now that’s an OSI‑approved license. In the past, Microsoft would say, "We put the source out there. It’s open source," but to a lot of people in the industry…

Blaine: It wasn’t really.

Scott: Yeah. To them, unless it’s an OSI license, they don’t know if it’s really open source the way the OSI defines it. So now it is. That leads to the question of, are you now starting to do some of the things that a traditional open source project would do? You’ve got builds. You’ve got bug tracking and issue tracking that people can participate in.

Do you ever envision a day where you’d be taking community code submissions?

Glenn: We’ve taken steps in that direction with what we call our Contrib community.

Before I worked at Microsoft, I used to work with a bunch of different open source products. I worked with NAnt and NUnit. NAnt has what’s called a NAnt Contrib Project. The NAnt Contrib project is where developers who have the source, are extending NAnt. They’re building plug‑ins, etc., because a lot of these products have a plug‑in model. They want to have a way of driving that back in so that the community can benefit from those enhancements or extensions.

We decided about six months ago to follow the same model and we created a set of Contrib communities. Actually, we didn’t create them, and I think it’s important that we didn’t create them. We worked with the community. For example, with Smart Client we engaged with people like Kent Boogaart, who created WPF CAB, which was his own extension to CAB that would allow you to build WPF applications with CAB.

We also worked with people like Bil Simser, who’s a known MVP who developed Smart Client apps. We worked with a whole group of people, Chris Holmes is another. We brought them together and said, "Hey, we want to make you guys as successful as possible and enable you to take our deliverables, extend them how you want, without us telling you which way to go, similar to the way you can with other open-source projects. We’ll provide a place for you to do that, and we will also work with you going forward. We’ll also hear your concerns and consider how we can fold that into the product."

We do also work with external resources as part of our core guidance deliverables. We have our advisory boards which I mentioned which participate in the design and give us feedback. We have our CodePlex Workitems where the community submits ideas that influence the design. And we even have members of the community (partners, SMEs, etc) that write the codebase itself.

Scott: Aren’t there models where other people have dealt with this? You take a look at something like the Linux kernel, right? Nobody really owns it. It’s an open source project, it’s covered under an open source license. IBM is a contributor to it. And if stuff gets found in there that infringes on somebody else’s intellectual property, a lot of times the community, or IBM, replaces that with code that doesn’t.

I realize it’s a gradual process, and Microsoft is moving towards more community involvement, but it seems like down the road there may be ways to structure this to where Microsoft is a chief contributor to these projects, but every committer may not necessarily be a Microsoft employee.

Glenn : In the Linux kernel, yes you do have community participants, but it is not a free-for-all where anyone just comes along and checks in code. It’s a regulated process with a core set of contributors. We operate in a similar fashion. We do have externals that contribute, but there is a process around those contributions.

Scott: Another thing that’s interesting, when you’re under an OSI license somebody could fork your code.

Glenn: Yep. And I just want to make clear that we don’t own the Contrib project. We’re not claiming any responsibility for the kind of code that goes into that. We might suggest stuff, like, "What do you guys think about doing this or doing that," but it’s completely up to the contributors what they want to do.

It is the model that you described. We may pour some stuff into Contrib, and we’ve talked about doing that, but essentially the people that own it is the community.

Scott: Right, right. And those different Contrib projects are essentially forks of your code, and because…

Glenn: That’s exactly what they are. In some cases, complete rewrites. For example, if you look at the EntLib Contrib, there’s actually an EntLib refactored project where somebody who works at Microsoft ‑‑ Scott Densmore, who helped write a lot of our deliverables ‑‑ is actually ripping apart EntLib and providing a new version.

Similar kind of things are happening in the CAB space. We just recently shipped another version of Smart Client Contrib that actually contains updates to our Updater Block, to get it to work on Vista. This is completely being driven by the community and it’s taking things to places where we don’t have the resources to take them.

Scott: That’s what I was wondering. Maybe down the road, the only thing that exists is the Contrib space, and people in Microsoft are contributors just like anybody else.

Glenn: That’s certainly a possibility that we would be open to, but it’s not really about us and what we want, it’s about the customers. Many customers that have serious concerns about using community contributions that might contain code that violate IP. In the case of patterns & practices deliverables because it’s from Microsoft, they have less concern. Other customers however are willing to take that to take that leap of faith. These are the same customers that also use open-source deliverables like NHibernate, Log4Net, Castle Windsor etc.

Scott: To me it’s really fascinating how the different models are shaking out. We also interview CIOs for things outside of "How Software is Built" and they’re very fond of saying, " I want one throat to choke. I want to know that I’ve got support. I want to know that I’ve got a company that’s standing behind it. That’s really important to me. It’s not about the cost of the software, it’s not even about free as in freedom. I just need stuff that works, and I need someone to hold accountable."

And then on the other hand, on the other side of it, you’ve got open source, right? Where you don’t seem to have those same assurances, but on the other hand the software really does hit the mark. There are people who are experts in their domain. There are people who build really interesting things that a "big company" wouldn’t necessarily think of. There are people who do some innovative things, or start with someone else’s idea and take it in a very different direction.

There’s benefits in all of that. So it’s curious to me what the landscape is going to look like. You take a look at a company like RedHat. They’ve got this open source product, but they don’t really have control over the Linux kernel, or Apache, or the things their customer absolutely depend on. Still, they guarantee that they’ll provide support on top of it, enterprise‑level support.

You’re saying that if p & p’s work was full open source, and the only out that existed was Contrib, some of your customers would have trepidation because they would feel like there was nobody they could really point to who would guarantee the quality of the code, who could guarantee fixes, and those sorts of things.

I guess what I’m saying is it’s a very interesting spot that you sit in.

Glenn: In a way, it can be the best of both worlds, with some caveats of course. What it means is there may be significant functionality that will exist because of the energy of the folks in the open source community, and that functionality will show up in Contrib but not in our core deliverables. There are other things that the Contrib community might do, that we might decide to incorporate into the core in the future.

Scott: There’s another thing that makes your position interesting. On one hand you might get feedback from the product team saying, "Hey, we’re not going to have this in the next version. It’s going to be a pain point. It’s something that you guys could take a look at."

On the other hand, you might have a lot of people in the community asking for a feature, but because you’re part of Microsoft, you know that the product team is already building that into the next version of the product. You don’t want to invest in what the community is asking for, because it’s already being built, but you can’t tell anyone it’s being built. The product team still has their plans under NDA.

Glenn: That certainly happens all the time. That’s certainly a challenge. But what I’m happy to say is that more and more we’ve been able to drive back the experiences customers have had with our guidance to the product teams, which has resulted in many cases in product offerings that come out based on that.

Scott: When I looked at stuff you produced a long time ago, for example, the Data Access Application Block, it seems like it was almost destined to be obsolete. Eventually Table Adapters got built into the .NET Framework, and that provided the same functionality.

Blaine: Our goal is to actually help migrate customers from what we produce, to the core product. That’s really our ultimate goal. If the core product addresses scenarios we’ve heard from customers, that’s a good thing.

Scott: Yeah. Like I said, you guys are in a fascinating spot in terms of being an open source project, or open source projects, you’re really pretty unique it terms of where you sit. Can you share anything about the directions in which you’re going? You’re obviously moving towards more open. There’s certain constraints on that. Anything that people should look for over the next few months?

Glenn: One of the things I think we’re moving on, and Blaine can touch on this, is bringing more of what we’re seeing to product groups. As an example ‑‑ and we’ve been trying to collaborate much more tightly internally ‑‑ one example is this new MVC framework. Want to talk a little bit about some of the work?

Blaine: At patterns & practices we’ve been supporting, as Glenn talked about, many of the common patterns in the UI space. MVC [Model View Controller] is a common one. MVP [Model View Presenter] is another one. And since we’ve been in the space, we’ve been working with the ASP.NET team to help define the MVC work that’s coming out of there.

A big part of this is really Scott Guthrie and his team’s vision. We are bringing some of the feedback that we’ve heard from customers to the ASP team.

Glenn: We’ve actually been working on the design with them. It’s really been a partnership. I think those kinds of things are efforts that you’re going to continue to see.

The other big thing that I think you’re going to see, is the fruits of a transition we’ve been going through internally within patterns & practices. We’re re-evaluating carefully at how we deliver guidance and what is the best method. , and we’re also looking at taking the principles of SCRUM that we apply within our teams and bringing it up to a higher management level with p & p. This includes having having a cross p & p product backlog that we can be very visible with customers about. We want to show, "These are the things we’re looking at. This is what’s a high priority. This is what’s not."

On the subject of how we deliver guidance, although many customers have nothing but good to say about our factories, there are other customers, that say they are too complex. They also tend to not be as applicable in in what we call "Brownfield scenarios" which are existing applications. Instead, they tend to be most useful when you are starting from scratch. Another thing we’ve seen is that industry-wide there has been a shift away away from comprehensive “do-it-all” type frameworks to a more pluggable services approach. Finally we’ve had a set of customers who tell us that the biggest value we can provide is to focus more on patterns themselves and how to use them (including samples and reference implementations) rather than framework type libraries that implement those patterns. We’ve heard thse customer concerns and are taking them seriously. We’re looking at how we can break things into smaller blocks. We don’t mean exactly like the earlier application blocks, but instead how to ship our deliverables in an incremental fashion that offers customers more options as to what they use.. For example if I want to use some aspect of the factory without having to take everything, then I can. And, we are also looking at patterns and how we can make them more a first class citizen in our guidance.

Around this, we’ve put a stake in the ground with the current release of the Web Client Software Factory and with our newly announced WPF Composite Client.

By getting these things to be smaller, we can ship more of them more frequently, we can make more intelligent decisions about what we ship and what we don’t ship. We can build guidance that has more applicability in both the brownfield scenarios and well as greenfield — which is new development. We also give customers more choices as to how they incorporate our guidance within their environments.

Ultimately, we can reduce the complexity in evaluating and using these deliverables to make them approachable to a wider audience.

As you can tell, we’ve certainly got a lot of work ahead of us.

Scott: Thanks for talking. You opened up an interesting subject at the end, and maybe we could talk again in the future about it.

Blaine: You bet.

Bookmark this: