What we dislike about TFS

Overall we really like TFS, but here are a few things that are less than desirable.

• "Friendly Names" (actually unfriendly for us) for fields such as "System.AssignedTo" or "System.ChangedBy" is a major oversight on Microsoft's end. Let's say you have an employee John Doe who's Active Directory name is "Doe, John (Company 1)". John then moves to company 2 and the Active Directory name changes to "Doe, John (Company 2)" This causes major issues in TFS as because it's integrated with Active Directory the work items are invalid and can't be modified. Fields like "System.AssignedTo" can simply be updated by the user. Hidden fields like "System.ChangedBy" can't be changed by the end user. For this issue call Tech Support and get the TFSLocalize utility. For one user it's not a bad solution, but let's say you have 200 users (like we do) and Company 2 decided to be called Business Unit 2. Now we have 200 users who need to be changed. TFSLocalize stinks as you have to map out old user (i.e. Doe, John Company 2) to new user (i.e. Doe, John Business Unit 2). While we're not up and running yet, this potentially is a major, major issue!!!!

• Administrating TFS, Share Point, and SQL Reporting Services in three different spots is laborious. In fact without the TFS Administration Tool, we'd be in a ton of trouble. Trying to keep track of permissions and users in three separate spots for 200+ users is unobtainable. So if you're new to administrating TFS, make sure to visit Codeplex (http://www.codeplex.com) and download the TFS Administration Tool (http://www.codeplex.com/TFSAdmin). Without this tool, administrating TFS is a nightmare.
  

• The out of the box Alerts stink. First of all there is no easy way (we know of) to "subscribe" all the users. Instead each user has to "subscribe" themselves. And worse yet, they need to know their SMTP address. Imagine the pain of telling your Vice President they have to type in first.last@company.com. They barely know how to tie their shows for goodness sakes. To get around this we're simply avoiding the concept of subscribing yourself and using Mariano Szklanny's web service to do all notifications (http://staff.southworks.net/blogs/mariano/archive/2006/04/14/411.aspx). I'd suggest a similar approach if you're a large team like us.
  

• No web interface for work item tracking. Developers love the work item and source control integration located in their IDE. On the other hand, managers hate having to open up Visual Studio 2005 just to approve a Change Request. While this seems like something trivial, a nice bundled web interface sure would be nice. Hey Mr. Gates, buy Teamplain (http://www.devbiz.com/teamplain) and make it part of your solution!
  

• Code policies on the client side instead of server. Out of our 200+ users, 100-125 are Java developers using Teamprise (http://www.teamprise.com). We like Teamprise, but wish we could enforce a policy like "Require Associated Work Items." Nope can't. All the policy code is local to the Team Explorer install. Dumb! If you've never used Teamprise give it a shot. It's a very nice tool with WONDERFUL technical support.
  

• No hierarchy for the work items. Rhetorical question; if Tasks are children of Change Requests, why can the Change Request close before the Tasks are closed? A nice hierarchy is needed. And Microsoft, don't give us "TFS is totally extendable to do all of these things you request." We're not in the business of developing configuration management tools. You are, so add hierarchy in for your customers.
  

• Can't remove or rename work items. For some management reason that supersedes any input I have, we're not using the Requirement work item for a Team Project that is already created. Instead of leaving it there to confuse users, we would sure like to remove it. Nope can't remove it. Not possible. Or how about when you create a new work item called WrognName. Opps I made a typo, this should be called WrongName. Nope, can't rename it. Not possible.
  

That's enough ranting for today. Again we like the product, but are excited to see the next release and what new offerings it has to address TFS's current limitations.

Work Items, Work Items, Work Items

February 2007 - Well this month has been interesting. I spent the first half on the beech in Hawaii with a cocktail, great wife, and a good book (actually four of them). And the second half here at work making up for the two weeks I had off. Makes you wonder if vacation is really worth it?

In January we looked into work item tracking as that is much of upper management's focus. They like the states and transitions and have hours of fun drinking coffee, taking golf, and designing elaborate workflows that no one understands. We're using the CMMI process templates and then making our (i.e. upper management) modifications from there.

In the Change Request work item we're changing the default states to Submit, Estimate/Evaluate, Implement, Verify, Close. Why? Not sure, but this is what the big wigs wanted. At our company we call Bugs, Defect Reports. From what we can tell changing the name of Bug is impossible if a Team Project is already created. So we negotiated and decided to call a Defect Report a Bug when in TFS. We changed a few fields and changed the states to Submit, Evaluate, Implement, Verify, Close. Again, we're at upper management's mercy.

Both Issue and Risk we left pretty much the same. We added a few fields, but for the most part they're out of box. We're not 100% sure on how to use Requirement. Another group is looking at purchasing what they call a Requirements Management tool so we'll probably wait until that effort fails before we start looking at the use of our Requirement work item. That being said, my boss just stopped by my cube and during a lively chat we might have found a use. More on that to come in future months. The Review work item we plan on making optional if they want to use it for code/document reviews.

Task is the most complicated. Tasks are where all our release related work items are stored. If our release manager wonders what are all the changes going into release 7.7, they simply look at all the Tasks with the Release Number (i.e. changed the name of Iterations to match our terminology) set to 7.7. If our other application tiers (e.g. Application Tier) who are dependent on us needs to know all the changes, they typically look at the Tasks. Change Requests are typically to high level for developers. Using Tasks we also get a good idea when it's time to baseline. I won't get into all our states and transitions (far to many to explain here), but basically we have a state called Code Complete. Before we baseline a release (e.g. 7.7) we look to see how many Tasks are in Code Complete. Ideally all of 7.7 Tasks should be, but as it happens a few are always still in Active or Code Review. We typically move forward with the baseline, but know there is work to be done on the release before a comprehensive round of testing can start.

Development is also supposed to create Links so we have a good understand of what Tasks created Bugs, and what Change Requests or Requirements, Tasks are assigned to. In a perfect world (which we're far from) a Change Request or maybe Requirement (in the future) is submitted. One or many Tasks are assigned to Change Requests or Requirements. Then during the Task's Testing state, Bugs are created and Linked to the Task. Taking this further, Reviews, Issues, and Risks can also be Linked to the Task. This all being said, without rules to enforce a Linking hierarchy, it's really hard to make sure people follow these guidelines.

We also created two new work items. The first is called Build where we log all build results. We're a Java shop and not using Team Build (currently using Anthill which we also wrote a TFS adapter for http://bugs.urbancode.com/browse/ANTHILLOS-261) but still want to keep all our build results (e.g. build failed/succeeded) in TFS. One stop shop for all information. We simply create a Build work item, update it with the needed build information, and close it when the build is done. Seems to work alright. Then we also created Environment CR, which is used to track environment changes. These are handled differently then other Change Requests so that is why we created a different work item for it.

Anyway, probably enough information for the month. We'll touch base in March when all of what I said above changes. Happy winter!

TFS Migration Errors

January 2007 - Ah one month down in our Team Foundation Server (TFS) implementation! We've actually been quit busy even though upper management might not think so. Little do they know, while we wait for our PROD hardware to arrive we've had a demo copy running for months on some antiquated hardware we found under old C++ programming guides.

This past month we've been concentrating on designing workitem types for our CMMI process improvement implementation that we're so proud of, and spent a lot of time doing test migrations from Visual Source Safe (VSS) to TFS. It's in the VSS to TFS migration spirit we'd like to concentrate this month's post on. We've run (actually more like stumbled) into some valuable information that we're hopeful future (or current) TFS users will find valuable.

First some statistics from the VSSConverter tool. So far we've migrated 55,389 files with 137,547 "actions" in around 7 hours and 45 minutes running on desktop machine (996 MHz processor with 512 Mb of RAM). From what we can gather an "action" is any history item (e.g. edit or add) in VSS. We feel this is pretty acceptable and have no issues with the migration duration.

Now onto the errors and warnings. During our test migrations of VSS to TFS we've run into multiple instances of the following errors and would like to share our observations and thoughts of why the errors might have happened. Now I'm skeptical of most hypothesis, including the ones I come up with. So take this as is, and feel free to provide feedback if you agree or differ with our findings.

Error/Warning 1:
"Unable to scan history due to VSS Error: File or project not found"

So far we've found this error to present itself when a file has been "Destroyed" in VSS. We are guessing that the act of "Destroy" is recorded in the VSS history, but the actual file/project is missing and thus VSSConverter can't do the migrate and simply flags it as something it can't do. We guess that kind of makes sense, but once in TFS you do loose the fact that something at one time was "Destroyed." For hard core configuration management pundits this could be like arguing if a tree falls in the woods does it make a noise if no one is around to hear it? That is, was something ever created if there is no history of it?

Error/Warning 2:
"TF60096: Unable to migrate due to Team Foundation Error: The item already exists."

The most common cause of this error (we think) is when you have project name conflicts. For example, we once had a source tree called $/prod3 that was created, filled with source, deleted, then created again, and filled with source again. Don’t even get me started on why! This was resolved for the most part by taking smaller chucks lower in the hierarchy. See this posting one the background and some examples of how we got around it. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=973933&SiteID=1

Error/Warning 3:
"TF60096: Unable to migrate due to Team Foundation Error: The item could not be found in your workspace."
"TF60096: Unable to migrate due to Team Foundation Error: TF14022: The deleted item does not exist."
"Unable to migrate. "

We've seen these errors when no file history was migrated at all. We get a message in the comments saying "Tip Version match Checkin---- DO NOT MODIFY. VSSConverter comment. Verification complete ----" which think is due some combination of deleting a file, recovering a file, and then renaming it (as a side note it's also a pretty lame error message). For example this is what we saw in the VSS history. I've purposely XXXXXXX'ed out the intern ;) who exercised themselves with this renaming experiment.

***************** Version 63 *****************
User: XXXXXXXX Date: 10/14/05 Time: 10:23a
Renamed application_STABLE.xml to application.xml
***************** Version 62 *****************
User: XXXXXXXX Date: 10/07/05 Time: 12:04a
Renamed application.xml to application_STABLE.xml
***************** Version 61 *****************
User: XXXXXXXX Date: 10/07/05 Time: 12:04a
Renamed application_STABLE.xml to application.xml
***************** Version 60 *****************
User: XXXXXXXX Date: 10/07/05 Time: 12:04a
Renamed application.xml to application_STABLE.xml
***************** Version 59 *****************
User: XXXXXXXX Date: 10/06/05 Time: 2:20p
Renamed application_STABLE.xml to application.xml
***************** Version 58 *****************
User: XXXXXXXX Date: 10/06/05 Time: 1:39p
Recovered application.xml
***************** Version 54 *****************
User: XXXXXXXX Date: 10/06/05 Time: 11:02a
Deleted application.xml

In conclusion, we hope you find this information valuable. Feel free to comment if you have additional information or disagree with our conclusions.

Welcome!

December 2006 - Since April I’ve been working on a tremendous opportunity my employer (who’ll I do my best to keep clandestine) presented me to replace our source, defect, and change management system. This blog is a living story of our implementation. First a bit of background to get us started.

At our company these three disciplines (source, defect, and change management) are under the configuration management umbrella so this could be, and probably should be, called a configuration management solution. We currently use a tool for source control management (i.e. Visual Source Safe) which while is cheap (we quit paying for it years ago) and easy to use, allows inexperienced users to actually delete the database files with no more than a “Do you want to permanently delete these files” message. In fact we’ve had this happen twice to us almost a year apart, and interesting enough both on Friday afternoons. We then use, and grossly overpay for, a defect management tool which the vendor would like to retire yet keeps it around for the simple fact that, as I stated before, we grossly over pay for it. Lastly we use yet another autonomous tool for change management that while we’re comfortable using, has no connection to either the source or defect management tools. So while we like assume everyone is doing their change management paper work, we have no way to enforce it and none the less have little idea about what features are truly being changed or added.

With this all being said, you can see why upper management (a term my statistics professor liked to call anyone who has budgetary power) was interested in spending some expense dollars for a new (preferably integrated) source, defect, and change management system. I won’t get into the details of how we narrowed down the vendors on our short list, but will say our evaluation was simply an extension of an existing effort in another business unit on the other side of the bathroom. To avoid the months of vendor background and demonstrations they gathered and witnessed, we simply took their short list which included IBM’s ClearCase/Clear Quest, a hybrid solution using Serena’s TeamTrack with Perforce’s Perforce, and Microsoft’s new Team Foundation Server (TFS). It was also imperative both business units stayed in synch with our choices, for while we’re currently separate, we could someday be integrated. As a side note, to some of us two bathrooms and an elevator bank are the only things that really keep us separate anyways.

We spent the next three months digging into the details of these tool sets and when the dust settled and political landscape was observed across the hall, we decided to pilot and then purchase Microsoft’s TFS. The one really interesting nugget we took away was that if you look at source, defect, and change management separately there is little differentiation between vendors. The value is in the bundling of the offerings and making the bundling seamless and painless as possible. Most of you reading this column might ask why we would pick a newly released piece of software like TFS over industry bellwethers like ClearCase/Clear Quest and Perforce. This is a great question so let me address it with a few highlights.

First of all we’re constrained by a pretty tight budget. We don’t have the expense dollars to explorer solutions that will cost one or two million dollars which is what ClearCase/Clear Quest would have costs us. Now the vendor will come back and say that we’re looking at it all wrong and we should be looking at the purchase from a “return on investment view” and honestly I can’t disagree. But there is something to be said about a solution that is five to ten times more expensive than another solution and lengthens the time it takes to get a ROI. In the fast changing world of technology lengthening the ROI is scary and risky. ClearCase/Clear Quest is known to be very expensive to both purchase and support and really priced out of our league.

Secondly, being part of the group who not only made the recommendation to purchase TFS but also support it, administration is something key to our group. Again ClearCase/Clear Quest is known to be laborious to administer (I’ve never had the opportunity so I’m taking other’s opinion on this) and the TeamTrack/Perforce hybrid would take some added integration work which we’d like to avoid. With source, defect, and change management all integrated in TFS we felt it was the most straight forward to support and easiest to train end users to use. We’re not to say TFS is not without its faults, but we’ll save these for another posting.

Thirdly, as we said above we sampled the political winds across the hall to make sure we’re in alignment in our tool choices. We’d hate to choose tool X while the other business unit chooses tool Y and then migrate them to tool Z if (or when) we become one again. While ClearCase had some momentum early, there was little talk of how defect and change management were going to be handled. Clear Quest is the obvious choice, but was not adequately discussed. TFS on the other hand presented itself as a solution fully bundled and integrated, which with the help of some influential folks escalated TFS to the top of the other business unit’s list.

Any way, enough with the details. In conclusion we hope you find this blog both as an interesting read and something which provides helpful hints when you go about implementing your TFS solution. While we make no promises, we’ll do our best to make a posting around the beginning of each month. Enjoy!