This is my first blog and I’m pretty new to it so I’m pretty certain I’ll violate the accepted standards of conduct for a while so please bear with me while I come up to speed.  I take feedback well 🙂 My first experiences with community were a few years ago when we announced the .NET Framework.  I worked on that for years in silence and it was huge when we released it.  It was a ton of fun and it represented a big shift for Microsoft and for the industry.  Some of you may recognize my name from my infamous posts about deterministic finalization (and hopefully you aren’t still angry at me :)) It was a hugely difficult decision for me to leave the CLR team.  The people I worked with on the .NET Framework became some of my closest friends and the technology was some of the most exciting I could imagine.  I worked on the CLR for 5 or 6 years and for personal reasons I needed to make the move from Redmond to the east coast.  I couldn’t continue the job that I had because it wasn’t possible to do remotely.  I looked around at opportunities including (staying in a different role in the .NET Framework).  At about the same time we were looking at getting seriously into the lifecycle tools space. I’ve always had a passion for development tools.  I like to work on things for which I am a representative customer.  That way I can really relate to our users and understand their pain and the value of our products.  In my background, I’ve done compilers, parser generators, assemblers, linkers, etc.  I and two others (Ken Felder and Larry Iversen) founded One Tree Software in 1992 to create SourceSafe.  That was a great experience (and perhaps the subject of another blog at some point). In any event, the opportunity to participate on the ground floor of creating a suite of tools to dramatically improve the productivity of team software development was absolutely irresitable.  In watching the .NET Framework grown from a“small“ team of 25 people to a “large” team of hundreds of people integrating closely with partner teams that added up to thousands of people, I learned a huge amount about the process of software engineering and the tools that can help make it more effective.  I was eager to capitalize on that and turn it into a set of tools that our customers could use to make their lives easier. Historically we (developers at Microsoft) had the view that our development was, somehow, more sophisticated than what most other people did.  The thinking went that there are relatively few organizations have development on the scale we do – either measured in number of developers/testers/… or in terms of number of components/lines of code/….  It followed then that since our scale was so much larger that no one needed the tools we built internally to help manage our process.  As a result we developed a huge set of tools that we used internally but we didn’t sell.  I think this sentiment is what kept us from getting serious about lifecycle tools earlier. When we started talking to enterprises to understand the problems they face to get input into our lifecycle tools plan, we found that although our scale is much larger than most organizations, the problems we face internally are virtually identical to the problems that our customers face:  Many of the tools and processes we had built internally were directly applicable to our customers. Before I go any further I want to make it clear that I don’t think we’re so smart that we’ve solved every problem and that everyone should just do what we do.  We are still learning and the process of building/productizing these tools has been a good learning experience for us.  Further, we understand that every organization has their own process.  The processes tend to have a lot in common but a lot of differences too.  As a result of this one of the lynch pins of our Team System design has been customization and extensibility. In addition to customization/extensibility, early on we identified integration (both UI and data) as one of the defining characteristics of the Team System.  On top of that we set the requirement that we were building tools that we could (and would) use internally at Microsoft.  We believe that both Microsoft and the industry will benefit greatly be coupling more of our internal tools and processes to the ones that we encourage our customers to use. If you look hard at Team System it is a combination of productized versions of tools we developed over the years and use internally (e.g. static analysis, profiling, work item tracking, …) and new tools that we are developing (version control, load testing, unit testing, …).  Generally, we chose to build new tools where the internal versions of the tools that we use were deemed not to be the best starting point for where we want to be. I genuinely hope that you guys are going to love the work we are going.  If not, please tell us why not.  We can’t do everything at once but we listen carefully and if it’s broken we will fix it.   I don’t know how regularly I’m going to be able to blog.  I’m just going to have to see but I commit that now that we are public I will dedicate significant time every work working with all of you out there in the development community to understand your challenges, improve our tools and (hopefully) help solve your problems. Cheers,

Brian