Ok, I’m on a Microsoft Research kick today. I admit it. Some of you know what I’m talking about – you find one cool project and that leads to another one, and another one and before you know it you’re finding and reading a paper titled “Mining Software Effort Data: Preliminary Analysis of Visual Studio Team System Data”.

It seems that some really smart people on the VSTS product team got together to analyze actual VSTS data and prove that (in software development) smaller features can be estimated more accurately than larger ones. In other words, there is a positive correlation between actual estimation error with feature size.

Hmm. Now I could insert a wise crack here, but I won’t. Think about it. This is empirical evidence based on actual data. This rocks! I see this as the beginning of many successful data mining adventures of the TFS warehouse.

Basically the research focused on the actual development of VSTS 2008 and the product group’s predicted effort estimates for 55 specific features. They then updated the actual and remaining effort tallies throughout the development process and then collected the data directly from TFS, performing statistical analyses to identify estimation error and relationships between error and effort metrics.

I was talking TDD with Doug Seven at Tech-Ed last week. He gave a great presentation on Agile Development with Team System 2010. Afterward we were brainstorming on ways to get people to write unit tests. We both agreed that it has to be understood and driven by management. While we may never get management to understand the intricacies of unit testing or the discipline of TDD, but we may be able to appeal to their desire for software quality. On that point, Doug guided me towards this document on Microsoft Research from January 2008.

The authors (Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie Williams) conducted case studies with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

Finally, some empirical evidence supporting the practice of TDD.

I met up with the Altova folks last week at Tech-Ed and asked about any cool improvements or features in their 2009 version of DiffDog It turns out there are two new, albeit surprising, features in there: compare and merge (the contents of) database tables.

It looks pretty good, and very similar to Microsoft and Red Gate’s products – just surprising to see it in an XML compare/diff tool.

As I was explaining how the Build > Deploy process is radically different this week, a question came up about licensing restrictions around the vsdbcmd.exe command-line utility that ships with the GDR. Here’s a quick history lesson:

The Pre-GDR Way

The Build process analyzes the target connection and then assembles all of the various .sql scripts into one large .sql script. The resulting script would contain CREATE or ALTER statements depending on what it found when it studied the target connection. The script also contains other custom scripts and variables you want to define. The problem is that this Build process requires access to that target environment. This was not always a possibility – either the developers didn’t have permissions, or ISVs didn’t have physical access to their customer’s datacenters. Finally, the Deploy process would then just execute the big .sql script against the target connection, which could be done using VS, SSMS, SQLCMD, etc.

The GDR Way

The Build process generates a .dbschema file which represents the current schema definitions of the database project in a single, easy-to-handoff XML document. This document has accompanying scripts and manifest files as well. The Deploy process then creates the .sql script and (optionally) executes it. The Deploy is now the only connected operation and it can be performed from Visual Studio or by using the new vsdbcmd.exe command-line utility. The major difference is that Build doesn’t need access to the target database, only Deploy does. This rocks, because now you can just give the .dbschema file to that department’s DBA or that customer’s datacenter admin, etc. and only they need access to the target to generate the proper script and to execute it. Problem solved.

… but question raised: what about the licensing of the vsdbcmd.exe file? Can the developer or ISV just give it to their respective user to deploy the changes?

The answer (thanks to Ted Malone, SQL guru and VSTS MVP) is YES, as explained in this article by Gert Drapers.

BTW - GDR R2 is available so you should download it now!

I’m pleased to announce that fellow Accentient Consultants David Starr and Michael Vincent have been named Team System MVPs!

David Starr is the founder of the Elegant Code community blog and podcast series, and also organized the recent, highly successful Boise Code Camp. David has over 18 years of experience in software development and has held numerous leadership positions in technology teams. He is a frequent speaker at technology conferences, a writer, and is involved in several .NET and Agile professional organizations. His passions include Agile software development, building strong teams, Application Lifecycle Management, Visual Studio Team System, and .NET.

Michael Vincent has been actively involved in user group communities since the early 90's, founding both the SoCal .Net Architecture group, also known as the International Association of Software Architects Southern California Chapter, and the Orange County C# Developers group which became the Orange County .NET User Group. Mike is a frequent presenter at local and regional user groups and Southern California Code Camps and has served with INETA as the California Membership Mentor.

Congratulations to both for this well-deserved recognition.

I'm pleased to announce that the Team Foundation Adapters project is up and running on CodePlex. The project description is as follows:

Team Foundation Adapters make it easier to do proper unit testing of applications that utilize the Team Foundation Server API, by providing a simple mechanism for mocking the commonly used sealed classes in the API, which cannot otherwise be mocked.

This is not vaporware folks. There's a working implementation, complete with sample unit tests. The project does not cover the entire Team Foundation API just yet. But it establishes a clearly defined baseline that will grow as needed.

Please have a look at the project and let me know what you think of this approach. If you like it, be sure to tell your friends about it. 

Many thanks to Jeff Bramwell, William Bartholomew, Martin Woodward and Mitch Denny for joining up as contributors. If you're interested in contributing as well, please let me know.

I’ve really been enjoying my Samsung 128GB SATA 3.0Gb/s Flash-based Solid State Drive (NSSD). Per Doug Seven’s advice, I’ve been copying over my existing Virtual PC 2007 hard drive images to the SSDD, and booting them up with Hyper-V. For the most part, there hasn’t been a problem, except yesterday I started receiving “General Access Denied” error message, something like this:

VMMS Account does not have sufficient privilege to open attachment 'E:\Hyper-V\Windows Server 2008\Windows Server 2008.vhd'. Error: 'General access denied error' (0x80070005).

There’s a lot of chatter on the forums about this, but essentially it comes down to having to give the Network Service account (for the Hyper-V Image Management Service) adequate permission to the VHD file. There are several ways to do this, but I just gave the Everyone group (Users in Windows Server 2008) full control under the Hyper-V folder. Fixed!

As a follow-up, it turns out that this is a bug for systems running Intel motherboards and Intel released a fix back in November 2008.

In this economic climate of cut training, cut travel, and general layoffs, it is more important than ever that we keep our technical chops and strong relationships in the development community. That’s good stuff, because:

The 2009 Boise Code Camp and Tech Fest is open for business at BoiseCodeCamp.org.

Sessions are already being registered on the site and we are off to a great start.

This year we are trying something a little different and are hosting 2 sets of sessions throughout the day. In years past it as been apparent there is an appetite for technology sessions that are not necessarily based on code. Typical interests are in Agile development practices, Project Management subjects, Information Technology topics (read networking, virtualization), and anything infrastructure related like IIS, Exchange, and SharePoint.

Yes, Virginia, those people do exist. And, in far greater numbers than those who have the proper usage of  “polymorphism” in their vocabulary. Thus, Tech Fest is born.

Last year’s Boise Code Camp attracted well over 400 people and with the addition of Tech Fest this year we are hoping for upwards of 600 attendees, making this the biggest Code Camp in the Pacific Northwest. We are lucky enough to attract speakers from all over the west and this is now the single biggest technical event in Idaho.

We truly support and welcome first time speakers and there is room for everyone to be involved in some way. Even if you are a short plane ride away from Boise, I encourage you to attend. It will be worth your time and fun will be had by all.

I hope you can attend, present a session, and finagle your employer into throwing us a sponsorship so we can pay for coffee. Of course, the only really required here is your attendance.

I look forward to seeing you there.

There has been a vacuum of really good, actionable information on MS Build and Team Foundation Build for developers. I’m pleased to report that this is no longer the case! Inside the Microsoft Build Engine, by Sayed Ibrahim Hashimi and William Bartholomew, fills the void with a book that serves well as both a learning guide and a reference tool. Here’s the product description:

"The build process when code gets assembled to see how and how well it works is a critical step in software development. Developers had few options for customizing the build process before Visual Studio 2005 and Visual Studio 2008, but the Microsoft Build Engine (MSBuild) enables developers to customize each step during a build. MSBuild is extensible and uses an XML file to describe each step, allowing the build master or developer to easily change and augment how projects are built. This book offers hands-on guidance for customizing MSBuild, and provides a cookbook of examples on Web deployment, automated releases, and other essential topics. It also covers Visual Studio Team Foundation Build, the build engine in Visual Studio Team System."

If you have anything to do with automated builds using Team Foundation Server, this book is a must-have. I know this for a fact because I had the opportunity to serve as a technical reviewer for the book.

One of my non-technical enjoyments in life is listening to the This American Life podcast, from Public Radio International. It isn’t always my political cup of tea but it is always entertaining.

I was catching up on some past shows recently, when I ran across this episode:

December 19, 2008: “Ruining it For the Rest of Us.”

The prologue to this episode is the first 13 minutes and is a wonderful discussion of team dynamics. I strongly suggest downloading and listening to it.

From the This American Life website:

A bad apple, at least at work, can spoil the whole barrel. And there's research to prove it. Host Ira Glass talks to Will Felps, a professor at Rotterdam School of Management in the Netherlands, who designed an experiment to see what happens when a bad worker joins a team. Felps divided people into small groups and gave them a task. One member of the group would be an actor, acting either like a jerk, a slacker or a depressive. And within 45 minutes, the rest of the group started behaving like the bad apple.

How many of us have met one of these people on a team we have worked in? How many of us have committed the sin of being one of these people at some point in our careers?

The Jerk

The jerk is someone who attacks or insults others. The jerk is a voice of derision and operates by tearing down others. Tag lines of the jerk include:

• Are you kidding me?
• Have you ever actually taken a [fill in technical area of expertise] course?
• Do you have any idea what you’re doing?
• Lots of eye rolls

The Slacker

The slacker consistently endeavors to do less work. Typical slacker behaviors include:

• Lean back, feet up
• Texting another person in a meeting
• Commonly says, “Whatever.”
• Often overheard saying, “I don’t care.”
• Will ultimately be heard claiming, “This job doesn’t matter. Let’s just get it done.”
• Lots of eye rolls

The Depressive Pessimist

A depressive pessimist is a doom and gloomer. This is the person on the team most often nicknamed “Eyore”. Common Eyore traits include:

• Head down on the table/desk
• State that the effort is unenjoyable
• Overheard saying, “This work won’t matter when we’re done anyway.”
• Body language slackens and hunches down
• Lots of eye rolls

Some bad apple statistics

The following statistical findings were claimed in the study discussed in the segment.

• A team with a bad apple member will perform 30-40% worse than a team with no bad apples.
• The presence of a bad apple on the team results in less communication between others.
• People mirror bad behavior in working with others.

And finally, it comes to this: A team isn’t often elevated by its best member, but depressed by its worst.

Wow.