Last month in “Looking Ahead” (http://www.windowsitpro.com/article/articleid/47379/47379.html), I recommended that you attend the Microsoft Professional Developers Conference 2005 (PDC05) if you hadn’t previously been to PDC or Microsoft TechEd. PDC05, which runs September 13-16 in Los Angeles, is now sold out. In case you aren’t going, I’ll gather and share a couple of Microsoft’s more interesting announcements in the September 16 issue of Developer .NET UPDATE.
Interestingly, Microsoft has recently and quietly made a pre-PDC05 announcement that Team Foundation Server (TFS) beta 3 (a part of the Team System family of products) will be released in first quarter 2006, which is after the expected November 2005 launch of Visual Studio 2005. I say “quietly” because although Microsoft hasn’t concealed TFS beta 3’s release date, it hasn’t promoted the fact either.
I found out about the TFS beta 3 release date in Somasegar's WebLog (http://blogs.msdn.com/somasegar/archive/2005/08/22/451026.aspx). It’s interesting that Microsoft decided to deliver this information through a blog as opposed to a formal announcement. Understand that, although this information has been reported, I can’t find any other formal announcement, except for a link to Somasegar's WebLog entry on the Visual Studio 2005 Team System Home page (http://lab.msdn.microsoft.com/teamsystem).
In essence, Microsoft is validating this blog entry as more than opinion, insight, or rumor. I would think this should raise some concerns inside Microsoft about how official the information in personal blogs might be. If a company starts making it a practice to officially reference blog entries, does this mean other blog entries can be considered official?
Note that I’m not against using blogs as sources of insight and other informal communication. Blogs are quite useful in that capacity. However, linking a release announcement on an official Microsoft page to a blog entry seems like a questionable practice to me.
Note that Microsoft isn’t letting this information out in a blog because it wants to avoid bad publicity about a schedule slip-up for TFS beta 3. In a Visual Studio Team Foundation chat session in May (http://msdn.microsoft.com/chats/transcripts/vstudio/05_0512_dn_vstf2.aspx), participants make it clear that they weren’t expecting TFS to ship at the same time as Visual Studio 2005.
The fact is that the information in Somasegar's WebLog entry deserves more attention than just blog treatment. S. “Soma” Somasegar gives not only the current release schedule for TFS beta 3 but also provides important information that developers need to know about this release. He reveals that there will be Go Live licensing available, that Microsoft is locking the data format so any data entered as part of the beta 3 release will be protected in the final product, and that there will be an upgrade path from beta 3 to the final product.
Should you download and start using TFS beta 3 when it becomes available? It depends on whether you need more than just a source repository. One role that TFS plays is to serve as a replacement for Visual SourceSafe (VSS). If that’s the only role you see TFS playing in your organization, odds are you aren’t going to find enough value beyond the VSS capabilities to really justify getting TFS. Although TFS has much better integration with Visual Studio 2005 and has a built-in remote model, there are enough limitations on both of these fronts that you might not find TFS (regardless of the release status) worth the additional cost. The free capabilities of VSS will probably be good enough.
However, if you want to improve the process by which you develop software, you should consider download and using TFS beta 3 when it’s available. The Software Engineering Institute (SEI) has a set of models related to the maturity of your software development process. The Capability Maturity Model Integration (CMMI) looks at whether an organization has a repeatable process. What do I mean by that? Well, it’s not uncommon for a company to take on similar projects that have similar goals and use similar technology. When an organization takes on the first of these projects, it gains insight into details about that project. With the second project, it should be repeating many of the same steps.
Unfortunately, what sometimes happens in organizations is that similar projects are worked on by different people. For example, suppose Bill and Tim work on a project the first time, then Rodney and Scott work on a similar project several months later. Rodney and Scott don’t have a good guide for their project because there’s no record of what Bill and Tim did to make the first project a success. Thus, the organization doesn’t have a repeatable process. Rodney and Scott can’t leverage the steps Bill and Tim took, even though the project goals are similar.
You’re likely aware of SEI and CMMI, but how do you apply them to a Microsoft development environment? Well, you can start by referencing documentation such as the Microsoft Solutions Framework (MSF). Unfortunately, trying to implement MSF in an organization requires tying elements together; this is where TFS comes in. TFS and Team System provide a framework of tools that you can leverage to reduce the cost of implementing MSF.
You can find a good introduction to MSF on the “MSF for Agile Software Development” Web page (http://lab.msdn.microsoft.com/teamsystem/workshop/msfagile/default.aspx). If you’re familiar with CMMI, you might want to check out the “MSF for CMMI Process Improvement” Web page (http://lab.msdn.microsoft.com/teamsystem/workshop/msfcmmi/default.aspx). These Web pages illustrate how TFS and Team System are designed to help you improve your software process by providing a central repository for much of your project work.
However, one thing you won’t see on these Web pages is a good estimate of how long it’s going to take your organization to achieve repeatable processes. Don’t be naive and think that the installation of TFS is going to suddenly give you a repeatable process. Achieving repeatable processes takes time--time measured in months. It’ll take a while just to read all the documents explaining MSF. For example, the “MSF for CMMI Process Improvement, Beta” download from the CMMI Web page is a 10MB fully compressed file that contains mostly text documents you’ll need to read.
Because of the time required to understand the process side of TFS, I recommend that you install TFS while it’s still in beta. Get your developers up to speed on the new source control features as you start to introduce your IT organization to TFS’s workgroup capabilities.
As I mentioned previously, the data format in TFS beta 3 will be locked and there will be an upgrade path from beta 3 to the final product, so TFS beta 3 isn’t going to put the software you ship to your customers at risk. If you install and use beta 3 when it first becomes available, the developers in your organization can start understanding how TFS and Team System will let them leverage repeatable processes, which will improve quality of their software and help reduce long-term costs.
