...the team blog of the patterns & practices team. For those of you who aren’t familiar with the patterns & practices team, let’s start with a brief introduction.

We are a small team in Developer Division (fondly known as DevDiv) and our mission is to provide guidance to developers & solution architects who are building applications on the Microsoft application platform. By providing guidance, we hope to make you more successful by speeding up your development, by reducing technical risk, and by helping you navigate the often confusing landscape that is the Microsoft application platform.

You’ve probably guessed from the first half our name that we’re rather enthusiastic about design patterns.  Design patterns describe solutions to common issues that occur in application design and development. A large part of what we do involves identifying these common issues and figuring out solutions to them that can be used across different applications or scenarios. Once we have the patterns, we typically package them up in what we call an application block.

An application block is a package of re-usable code, samples and extensive documentation that you can take and use to help you build your application. In some cases, the application block might include some form of scaffolding integrated into Visual Studio. We have application blocks to help you build Web, rich client, RIA, mobile, and Web service applications. We also have application blocks to help you with those pesky cross-cutting concerns—things like exception handling, data caching, etc.—that you need in pretty much every type of application. We’re working on application blocks for the Cloud, data access, and for SharePoint development. As well as application blocks, we have guides for testing, performance, security, and for general architecture and design on the Microsoft application platform.

As you can see we cover quite a bit of ground for a small team, which makes our life pretty exciting at times (and not always in a good way). To help us cope, we’ve adopted an agile approach to the development of our guidance. We do the whole agile thing, including test-driven-development, scrums, team rooms, pair programming, iterations, backlogs, etc. We always work with an advisory council of customers and interested individuals in the developer community who help to keep us honest and make sure we solve the highest priority problems first. During the project, at the end of each iteration we release everything to CodePlex. This allows is to get as much feedback as possible. With final releases published on MSDN. A typical project runs anywhere between 3 and 9 months. We also provide some guidance on agile development (hence the practices  bit of our name).

So that, in a nutshell, is the patterns & practices team. And this is our team blog. I bet you’re wondering why we have team blog and why it’s called "simplifying patterns & practices."

It’s true that pretty much everyone on the team blogs, tweets, Facebook’s, LinkedIn’s (should that be Links-In?), Channel 9’s, Dot Net Rocks and MSDN Magazine’s their work in patterns & practices. With so many communication channels and so many diverse projects and technologies it’s sometimes difficult to believe that we do, in fact, have a common mission and a plan! This blog is intended to help bring all of these threads together in one place. In the coming months we’ll have posts from many members of the team and they’ll describe their work and how it fits into our overall mission. We’ll also have posts from guest bloggers who are external to the team.

So why "simplifying patterns & practices." There are two answers to that.

Firstly, the guidance that we provide is meant to simplify your development life and leave you more time for blogging/twittering/surfing/watching Channel9/Action<T>’ing. 

Secondly it’s fair to say that some of our guidance has been on the, errrm, complicated side. We do focus on building real-world applications on a solid architectural footing, so some complexity is inevitable but still, we think there is a lot we can do simplify our guidance and improve the way in which we build, package and deliver it. We’re hoping to use this blog to document our journey and we hope that you will join us along the way and give us your full and frank feedback!

David Hill, Architect
May 2009