That said, there is still room for improvement and both the team and I understand there are still opportunities to improve. In all seriousness, the team at Microsoft wants to make TFS an approachable, no-brainer install decision for .NET teams, even small ones. This means they want to be able to compete for your attention with the likes of SVN, Git, Jira, Perforce, and anyone else making collaboration tools for developers.

The point of this post is for you to help me know what feedback I can give the TFS product development team as they look ahead to the next release of TFS. I am looking for legitimate feedback I can give the team on how to improve the TFS product.

Please bear in mind that I am interested in your feedback on TFS 2010, as TFS 2008 was improved upon 10 fold in the latest release. Also, I am not necessarily looking for feedback on Visual Studio, just the TFS side of the house. Please realize that the team who makes this product at Microsoft is just as committed and passionate about making great software as you are. They just really need your feedback to make the thing you want. In fact, they want to make a tool that every developer loves to use. Really. So what needs to change to make that the case?

Recall that TFS functionality is broken into the following major areas and I am looking for feedback on the 2010 version.

• Version Control
• Work Item management
• Team Foundation Build
• SharePoint integration (optional)
• Reporting and SSRS Integration (optional)

Thanks for anything you have. Thank you also for being respectful and not making this a bash-fest.

So here is a hidden performance increasing jewel you might find useful.  We can set the default open mode to be in full XAML view.

First thing you need to do is in Visual Studio go to your Tools ==> Options ==> Text Editor ==> XAML ==> Miscellaneous.  There you will see an option for “Always open documents in full XAML view”.  Check that box.

Now every time you open a XAML file it will open in full XAML view and give you one less thing to gripe about.

Folks, this product is getting better. That stands to reason. After all, this is basically version 3 of the product and you know what they say! Version 3 is the one to buy. Most of the kinks are worked out now.

Now, I won’t pretend for a moment that Team Foundation Server hasn’t had its challenges fitting in with agile teams. I think that has come from a history of development by a team that itself was learning and growing just like the rest of us. Now that many of the teams within Microsoft are practicing some form of iterative development with completed cycles of “all the way done”, we are starting to see the influence in the tools they are producing. And the effect is not half bad.

I have been using Visual Studio 2010 for a few months now, and with the recent release of the RC, I can see:

1. Performance is getting better (XAML).
2. Features are getting more solid (fewer exceptions)
3. The polish of the overall user experience is becoming a great example of an application I am happy to look at all day long.
4. The Team Foundation Server features being added are consistent with what we are learning to be effective as an agile community.

So, where’s the meat? What are these shiny features of which you speak, Mr. Starr? Well, here is a short sample because I am sitting in an airport listening to the chaos and I can’t think of it all.

I should also say that this is a very small list of features that I personally am really excited about. The rest of the world probably has other things they care about. These are mine because I believe they have to potential to really change life on a team for the better.

Layer Diagrams

There is a major focus in this release to add UML support to Visual Studio Ultimate. OK, not a huge fan and I know some people will dog on this feature, but I am all about the Layer Diagrams. These are diagrams that we can create just like the UML diagrams that Visual Studio now supports, but the value of a Layer Diagram is that it has teeth and can bite back.

Here’s how it works:

1. Create a Layer Diagram.
2. Draw your favorite design pattern or desired architectural separation model using tools in the Toolbox. In a simple example, this might be to create a model of the MVP pattern. In a large example this model might show the multiple layers in my solution that uses CSLA, Silverlight with MVVM, WCF, and Entity Framework. (Hi, Scott J You knew that was for you.)
3. Add some things to it from your solution. Drop things onto the diagram and into the boxes like classes, namespaces, and Visual Studio projects.
4. Now you can generate dependencies between these things and see the existing relationships. Yawn. Cool, but we get this with dependency diagrams, too.
5. Validate the model.
   
   Wait for it. . . Grok it. . .

   
   You got it! Yeah, that’s right. Validate the LOGICAL model of your application. This is so sweet it comes on a stick. This means that not only can I verify I haven’t violated my design with a bad reference or super egregious abstraction hole, but I can make this validation part of the build process and catch it if I accidently violate my own design later. Where I come from, they call that cool.

Way Better Work Items

This is non-trivial for teams who live every day of their lives in Team Foundation Server to manage their requirements and work queues. Sure, we might all prefer note cards on the wall, but for many this is simply not possible. And for those folks who use Team Foundation Server to manage their notecards, there are some great new things to make that task easier.

1. Hierarchical relationships between Work Items.
2. Agile planning Workbooks.
3. Seamless Team Project Dashboards.
4. MSF Agile 5.

Gated Check In

This is a feature of Team Foundation Build that will actually build and test your software before a check-in is committed to Source Control. The mechanical effect of this is simple: Code that would break the build is never committed to Source Control. The implications are far larger, though. Think it through for a moment. What would change in your daily life if you flat out were unable to commit code that breaks the build? The short answer is, “Quality goes up.” I bit more verbose answer is that I need to be more careful before committing my code.

Yes, I know other vendors have had this feature for a while. So what? So, Team Foundation Server shouldn’t have it too? It rocks and now we get it in Team Foundation Build.

IntelliTrace

I am not even sure how cool this is yet, only that it is. This feature is also known as Historical Debugging and gives the ability to step back and forth through call stacks and watched variables during a debug run. To be clear, that’s Back and Forth through time. So, the first time I hit the breakpoint, here was the status of the code. The second time it was this. And so on. Also, I can inspect all this data on system events (like CLR events) and can therefore tap into my app at a lot of different levels.

Now, I know that you don’t need debuggers anymore because every line of code we write is Test Driven and that means we don’t need debuggers, right? Yeah, sure you never need a debugger. As I said, this is just a wicked tool, but I am not yet sure how wicked. The community will definitely ferret that out over time.

Other Stuff

This only scratches the surface of what’s in Visual Studio and Team Foundation Server 2010. There are a lot more things, many of them bigger and higher profile than the things I mentioned. I just happen to be in love with these particular features at the moment. As I get deeper into things, I will let you know what I see.

One last thing, I know these tools get a lot of flak in some communities, but I feel comfortable with them. I also understand that many developers out there in the world don’t get to choose their tools. Often tools are assigned. What I see is that the 2010 versions of Visual Studio and Team Foundation Server really have raised the bar. I don’t feel like teams are still having to compromise on tooling to get everything they need in an integrated environment.

Will I still run R#? Well, yeah.

In this episode, Tommy visited with me about effectively applying Team System to some agile software development practices. This ranges from Continuous Integration to the tool aisle at your neighborhood Sears store, but I’ll leave that for you to discover.

• Tommy’s Blog
• Scrum for Team System
• Manifesto for Software Craftsmanship
• Visual Studio Team System

Get the show here

This will give you Data Dude functionality in Visual Studio for SQL 2008. Plus, this is where you get all Agile in your DB development. Unit testing stored procs and whatnot.

There are a lot of other features, too.

Application lifecycle management (ALM) regards the process of delivering software as a continuously repeating cycle of inter-related steps: definition, design, development, testing, deployment and management. Each of these steps needs to be carefully monitored and controlled.

Does this sound familiar? It should. This is YAW2QH2DS (Yet Another Way to Quantify How to Deliver Software). This smacks of other big acronyms you may be familiar with like CMMI or *UP.

I don’t mean to trivialize this with curmudgeonly developer attitude. The idea of measuring our organization’s maturity level in the software delivery craft matters. It matters because successful small companies typically get bigger, and the challenge to every one of these organizations is how to stay successful as they struggle with issues of scaling up. It matters because it isn’t good enough to compile and run software. It needs to work well, solve a good problem, and actually be delivered into the hands of users.

Measuring our organization’s mastery of delivering great software is also important for organizations needing to get back to a good solid quality baseline. When things get big quickly without a control mechanism (companies, code bases, my belly, etc.) they trend toward entropy. ALM maturity can help provide that control mechanism.

Don’t take that the wrong way. It am not saying, "Let’s use a manager’s tool to measure and manipulate those pesky developers."

Quite the opposite, what I am really saying is closer to, "Imagine never having to explain to management that unit tests are a good thing and worth the effort."

If we have a common reference for measuring our collective skills, we can agree collectively that we can improve in certain areas.

What if (brace yourself) the framework itself (the one your CIO bought off on) required that unit tests, measured code coverage, automated builds, and automated testing were present in your delivery cycle on order to be level 2? Now we’re cooking with a little more gas, eh?

Microsoft and ALM

So, guess what? Microsoft makes tools for software developers. Big news, but there are lots of tools that others in your organization use to complete the delivery cycle: System Center, MS Project, Project Server, Portfolio Server, etc. These are the tools used by people in your company up and down stream of developers in the delivery lifecycle. Go ahead and resent them, but wouldn’t it be nice if these things were used well and worked more cohesively with your tools?

There isn’t a terribly cohesive story when flowing things between these tools (phases of the ALM cycle) but they are getting there. The real value here should be:

• Tools that are frictionless to their primary users.
• Tools optimized for the specialist using them. Whether this is developers, project managers, program managers, IT helpdesk, system administrators, developers, or testers.
• Tools that seamlessly integrate, allowing passing the products of these tools between each other.

Obviously, Microsoft has a strong story for these tools as individual solutions. In the last few years, Microsoft tools have actually started to integrate more easily and this is why. Integrating them up and down stream to complete the ALM story will be a significant effort going forward. The Visual Studio Team System story is a particularly strong start for Microsoft in pursuing an integrated ALM line. The effort is underway to integrate the ALM story across all disciplines.

It’s Not Just a Tool Story

"Great," you’re thinking. So this is a part of world domination through tooling? Not exactly. The fact is that the tools themselves are being built these days to embrace many different processes or methodologies (read TFS Process Templates here). Project Management tooling is certainly due for an overhaul, but System Center has some shiny newness that is heading in the right direction.

As long as the base tools themselves continue supporting extensibility hooks, the community should be able to plug and play as desired. The key will be in getting full integration supported in the community tools. As an example, we really should put in the hooks for nUnit to integrate with Team Build for integrated reporting.

The bottom line here is the tools are getting more extensible along the stack as well. This means that we should be able to support any wonderful, decrepit, promising, or ill-advised silver-bullet process or technique that comes along. "Now don’t that make you sweat chickens", my dad would say.

The ALM Maturity Model

So what about the model itself? Exactly what is this all about?

The basic ALM model endorsed by Microsoft includes the following Practice Areas.

• User Experience (UX)
• Requirements Management
• Quality & Test
• Code Quality
• Architecture & Design
• Project Management
• Software Configuration Management
• Deployment & Operations
• Data Management

What I like about these areas is that it doesn’t really matter whether you are a waterfall-driven Inicorp Employee or dyed-in-the-wool Agilista, these Practice Areas can typically be agreed upon as important. We can also all agree that being mature (read: competent) in these areas is important.

How mature are you? Microsoft provides an online survey for evaluating the ALM maturity in your organization where you can see a measured range of maturity for each Practice Area and specific competencies within each area.

Think about the questions you would ask to gauge competency in these Practice Areas. I was surprised to learn that the online survey asked many of the same questions I would have asked. Nice.

So?

So, what’s the big deal and why is this different? I find a couple of things interesting.

• Several tool vendors are embracing similar ALM models, not just MSFT.
• CMMI is so 8 years ago.
• It’s not about tools. It is about tools that support the business we need to do.
• There’s a boatload of money coming behind this. Your executives will hear about this. This ALM TLA will come up in a meeting.
• This framework actually embraces, rather than eschews, Agile Software Development practices. Seriously.
• It gives your department lead something to brag about when you write unit test (don’t undervalue this one).

This has a chance. This has a chance to actually improve the craft and to improve the bottom line at the same time, and that’s a powerful combination.

• If you have installed any of the pre-release version, makes sure you use the Visual Studio 2008 Service Pack Preparation Tool 
• For Silverlight, make sure you remove Silverlight Tools Beta 1, uninstall KB949325, and then apply Microsoft Silverlight Tools Beta 2 for Visual Studio 2008
• Training Kit for VS 2008 SP1 and .Net Framework 3.5 SP1

SP1 description from MSDN:

Overview

.NET-based Windows application development benefits from increased Windows Presentation Foundation (WPF) designer performance and updated components for Visual Basic and Visual C++ (including a MFC-based Office 2007 Ribbon).  Web development improvements include enhanced the client-side script tooling (JavaScript IntelliSense). In addition to IDE performance improvements SP1 fully supports SQL Server 2008 and the ADO.NET Entity Framework.

The .NET Framework 3.5 Service Pack 1 (SP1) delivers more controls, a streamlined setup, improved start-up performance, and powerful new graphics features for client development and rich data scaffolding, improved AJAX support, and other improvements for Web development. Additionally it introduces support for the ADO.NET Entity Framework and ADO.NET Data Services, which simplify data access code in applications by providing an extensible, conceptual model for data from any data source and enabling this model to closely reflect business requirements.

Visual Studio 2008 SP1 delivers:

• Improved WPF designers
• SQL Server 2008 support
• ADO.NET Entity Designer
• Visual Basic and Visual C++ components and tools (including an MFC-based Office 2007 style ‘Ribbon’)
• Visual Studio Team System Team Foundation Server (TFS) addresses customer feedback on version control usability and performance, email integration with work item tracking and full support for hosting on SQL Server 2008
• Richer JavaScript support, enhanced AJAX and data tools, and Web site deployment improvements

The .NET Framework 3.5 SP1 delivers:

• Performance increases between 20-45% for WPF-based applications – without having to change any code
• WCF improvements that give developers more control over the way they access data and services
• Streamlined installation experience for client applications
• Improvements in the area of data platform, such as the ADO.NET Entity Framework, ADO.NET Data Services and support for SQL Server 2008’s new features