I typically ignore the Microsoft marketing machine: while occassionally entertaining, the messages therein are typically so void of detail, suspect of schedule, and full of noisy FUD that they are distracting. Recently, however, a colleague forwarded me a link to a presentation about Visual Studio 2005 Team System that I couldn't ignore, because of its use of phrases I remember writing several years ago.
I do respect Microsoft's work in this space: development is a team sport, and tooling for most domains requires far more than just a faster/better/cheaper compiler and debugger. In the VSTS Tech Ed 2004 presentation cited, Rick LePlante and crew presented Team Studio. What first struck me is his use of the phrase "friction free" development. About four years ago, Alan Brown and I wrote a paper on collaborative development environments (since published in Advances in Computers, volume 59 and also mentioned in my EclipseCon keynote provided in the references section of the blog). Rick is correct - though he's a few years late in recognizing it - in that integrated development tools are all about reducing the friction among different stakeholders. Speaking of stakeholders, the Microsoft presention here is also virtually the same as IBM Rational has described for several years with regard to our suites, and their mention of having a rich partner ecosystem is what Eclipse is all about, although the former is captive and proprietary while the latter is open.
Following the demo in Rick's presentation was interesting, but IMHO a bit naive: on the one hand, Team Studio does automate some of the mechanics of change control (that's a good thing) but it totally ignores the things that can be done to address the social dynamics of collaboration (that's a bad thing). Some of the things Team Studio automates simply adds some ceremony to what you'd get in a development team that was already jelled and embodied good communication patterns, but the scenarios covered by Team Studio didn't necessarily encourage those good practices in teams that were geographically and/or temporally distributed or already somewhat dysfunctional. Messaging, presence, the formation of small, temporary work groups, lightweight artifact workproduct versioning, the existence of a virtual team meeting space: these are collectively critical to addressing those social dynamics, and that's the trajectory that I see such tooling needing to go (also as I explained in the EclipseCon keynote).