The Politics of Team Foundation Server (TFS)

Recent W2-labor-camp events have inspired me to take careful notes for the TFS ‘game’—right about now, in spite of being described by management as one who writes “elegant” code, I’m feeling like a loser:

• The ‘secret’ of looking “good” in TFS is to have a high Work Item velocity—this means an impressive number of items open and close under your TFS credentials.
• Do not work under a ‘large’ Work Item (a veritable silo of several tasks). Break the Work Item into several smaller ones. Failing to do this can be turned against you by the blame seeking and gratuitously criticizing. Do not overlook your generosity when you add, say, a generic base class (or any other generic “helper” code) as preparation for completing a task—record such preparation as a TFS Work Item. You cannot trust management to remember such generosity—especially when they are cracking under pressure from their bosses.
• Do not mark any Work Item (like a Bug) as “Resolved,” “Closed”—or any state of finality/abandonment when this is actually not the case—especially when you are not the original author of the Work Item. Do not do this for any “good” reason (like trying to break a large item into several small ones) because this de* *facto falsification can be turned against you by the conscious/subconscious accusations of a well-meaning manager. Assign the task to someone else before you resort to this.
• The comments that you enter at Check-in should also be listed under the “Fix” tab for bugs. This is meant to communicate the amount of effort involved in fixing the Bug. In general, error on the side of writing too much for a Work Item.
• Talk to management offline every week about the quality of your performance as an often fictional character in TFS. This weekly frequency is based on agile development. Avoid being surprised by their comments.

rasx()