Looking Ahead to 2010

No, this isn’t another prognostication post foretelling the woes of the world for the next year. This is a note to everyone who hasn’t yet played with the Visual Studio ALM tools and Team Foundation Server 2010.

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.

?

?