Sean Collins

sean [at] seanmcollins [dot] com

GPG Key ID: 0xf60f564978913931

sean [at] coreitpro [dot] com

GPG Key ID: 0xA1D7E590

profile for Sean at Stack Overflow, Q&A for professional and enthusiast programmers

Tracking developers in TFS vs. GitHub

One of the most difficult aspects of managing a team of developers, is how to track what is being worked on, and by whom. In scrum, the daily scrum is the first opportunity for all developers to report what they have done the previous day and what they intend to do today, on a relatively high level.

Yesterday I worked on Work Item #7605, and today I will be working on Work Item #2859

At that point, if a manager wants to see what code the developer did when working on #2487, he can open up the work item in TFS and the check-ins that the developer associated with the work item will be in the links section and also in the history.

Work item 7605

Changeset linked to work item

Seems quite straight forward, right? All the information that a manager could ever want is right at their fingertips.

Why It Rarely Happens when Developers use TFS

Frankly, the set of tools that TFS provides developers are so unwieldy and inconvenient, that forcing developers to associate their work with a work item, otherwise their code cannot be checked-in, is really the only way to ensure total compliance.

Just look at the instructions that a developer has to follow in order to associate a pending change with a work item. It’s extra steps on top of an already busy UI!

The more difficult it is to associate check-ins with work items, the less likely that developers are going to be proactive and associate their work with work items. Hence, the adoption of draconian check-in policies that ensure compliance.

What happens when you make things easy?

When GitHub introduced Issues 2.0, developers could now reference issues (the GitHub equivalent to TFS work items) from their commits.

The response from developers was overwhelmingly positive. The amount of effort to associate code with an issue dropped to zero, since adding one of the following lines to a commit message automatically connects the commit with the issue in GitHub.

fixes #xxx
fixed #xxx
fix #xxx
closes #xxx
close #xxx
closed #xxx

Issues 2.0 and the ability for developers to reference issues in commit messages is one of many, killer features in GitHub. It is not all that surprising, since GitHub eats their own dogfood, while the TFS division at Microsoft had to undertake a large initiative in order to get to the same point.

The developers of TFS need to take some notes from GitHub and make things much easier for developers.