TFS API: Check if Server Path Exists

1 Reply

Disclaimer:  Rarely do I get a chance to totally geek out and write a post specifically about code.  I enjoy the change-up.  And hopefully some of you will benefit from this.

Ok.  On a recent project, I’ve been playing around with the .NET APIs that were made available for interacting with TFS. You can tell that the documentation for these API’s are a little more raw than what is available for the .NET framework components, but that is not to say they aren’t still helpful.

As part of my project, I needed to programmatically download files to the local machine from version control.  As part of my unit testing, I wanted to validate the source path before attempting the download.  Basically, I wanted the equivalent of the System.IO.Directory.Exists() method in the .NET framework, but that validates against version control.

After several minutes of searching, I found the VersionControlServer.ServerItemExists() method. This handy method basically combines the functionality of the File.Exists() and Directory.Exists() methods, switching between the two (or combining) by setting the custom ItemType enumeration.

Using this method, I can first validate the path, as the following example shows:

Dim fakePath As String = "$/MyFakeTeamProject/RoadToNowhere"
Dim vcServer As VersionControlServer = Nothing

'...initialize a reference to the version control server here...

'Perform validation against server path before downloading.
' This example works for both file or directory paths.
If Not vcServer.ServerItemExists(fakePath, ItemType.Any) Then
   Throw New Exception("Hey! The path you gave me is bunk!")
End If

…and for the C# folks:

string fakePath = "$/MyFakeTeamProject/RoadToNowhere";
VersionControlServer vcServer = null;

//...initialize a reference to the version control server here...

// Perform validation against server path before downloading.
//  This example works for both file or directory paths.
if (!vcServer.ServerItemExists(fakePath, ItemType.Any))
{
   throw new Exception("Hey! The path you gave me is bunk!");
}

Removing Local Source Control Files with TFS

1 Reply

One of the things in TFS that has been of little value to me is the “Latest” column, found in the Source Control explorer.  The intent behind this feature is a good one:  Be able to easily tell if you have the most recent version of a source file, or if somebody has checked in a new version since you’ve last pulled down code.  But somewhere between idea and implementation, something got lost.

View of Files in TFS

View of Files in the TFS Source Control Explorer

There’s an annoying little side effect to this feature.  If the developer decides to make changes to files outside of TFS – for example, deleting local files that are no longer worked on – TFS will not recognize that the developer no longer has the latest version.  This becomes very irritating when trying to re-download the files using GET LATEST.  Because TFS thinks you already have the files on your local machine, it will, by default, skip downloading the files.

Fortunately, Martin Woodward posted a solution on his blog a while back on how to correctly clean up your local files while, at the same time, keeping TFS in sync.  I consider this to be a bit of a hack, because it seems very unintuitive.  However, I haven’t seen any new features in TFS 2010 to lead me to believe that a more intuitive approach is being added.  So, either Microsoft isn’t getting much feedback on this, or they consider Martin’s approach to be the preferred approach…

Meanwhile, I’ve since found myself doing this somewhat frequently after finishing projects, in order to keep my local directories from piling up with old files that I no longer need.

Daily Scrum via Instant Messaging

Leave a reply

Agile Purists beware: The following post may cause uncontrolled vomiting, convulsions, gnashing of teeth or “soap box”-style ranting to anyone who will listen.

Alright, now that we’ve got that out of the way, let’s talk about that headline!

First, Some Context…

At work, I’ve just started working on a small three-person project to build a relatively simple Windows application.  Two of us on the team serve the roles of project manager/ScrumMaster, Business Analyst and Developer.  The third serves as our customer/acceptance tester.

Last week was our first week of our first two-week iteration.  Our “customer” was on vacation for part of the week, but we held our planning meeting ahead of time so that the other two could move forward and have something to show our third when she returned.  We implemented daily scrum meetings, but found them to be a bit excessive for just two people.  So, for part of the week, we held our scrums over an Instant Messager.

Doesn’t This Go Against the Agile Manifesto?

I asked myself this question at first.  One of the tenets of the Manifesto is the idea of “Individuals and Interactions over Processes and Tools”, with the implicit supporting argument that face-to-face communication is the preferred approach.  However, remember that these ideas are not absolute.  We do not have to promote  individuals and interactions by sacrificing our ability to take advantage of technologies and tools.  Instead, we should take advantage of tools and processes where it is beneficial to do so.

In our case, myself and the other developer sit on different floors.  Rather than walking to a separate floor for a 2-3 minute meeting every day, it made more sense to take advantage of a tool, like a phone or instant messager.

Why This is Not a Good Practice in General

Now, I’m under no illusions that this is a good practice in general, nor that it should become a recommended practice at large.  While there were some benefits in our specific case, this practice would quickly become unweildy as soon as we start adding more people to the daily scrums. Even with three people, I feel like more could be accomplished more efficiently if we met face-to-face (or, at the least, over the phone).

Conclusions

The point I want to get across is that we need to remain pragmatic in our approach to software/solution development, and not fall into the trap of following any manifesto, principle or practice so blindly that it becomes detrimental to the team.  It’s up to us to decide what makes the most sense for our specific situations.

The Secret: Wants vs. Needs

Leave a reply

Let’s consider the following statement:

Don’t always deliver what the customer wants;
Always deliver what the customer needs.

There’s a subtle distinction between the two parts of the above sentence, but it’s an important one.

Most of us have heard the argument "Do you really need that?" at some point in our lives, usually when it has to do with something we really want, and are willing to argue passionately about its inclusion in the realm of all things necessary. Usually, this "voice of reason" manifests itself as a parent, spouse or some incorporeal, 3-inch tall, white-robed, haloed dude – or chica – hanging out on your shoulder.

But I digress. The point is that it’s a good question to ask ourselves. Do we really need something, or is it just something we desire to have?

Wants vs. Needs in Software Development

All too often, we – the technical folks – will get a long list of requirements from our business stakeholders, some of which are necessary for them to do business, and some of which are fluff features, or “nice-to-have’s”. Unfortunately, it’s also common for these different category of features to be lumped together into the same set of requirements, and it’s difficult for us to tell which is which. It’s our own fault; we’ve conditioned our business partners to think this way.

So how do we tackle the list? Generally, I’ve seen it done one of a couple ways:

  1. We treat all requirements as gospel and just start running through the list until we burn out, project time and/or money runs out, or (rarely) we deliver everything.
  2. We start cherry-picking through the list, based on what we think the business needs.

Both scenarios have major implications. In the first, we risk burning out our teams, the business partners, or both. Burned-out folks tend to leave, or produce lower-quality results. In the second scenario, we are putting the decision of what is important to the business in the hands of the technical folks (as opposed to the hands of those who are actually doing the business work). I’ve got another post planned for this second scenario, so I’ll just leave it at that for now.

So What’s the Alternative?

Half of the Agile Manifesto talks about promoting Customer Collaboration and drawing focus to Individuals and Interactions. So, the first step is to get the business partner involved in the planning of what gets worked on first. After all, they were the source of the requirements, so they should have a good idea of what’s most important to them.

Using iterations (the backbone of iterative and agile methodologies) can also help to promote adaptive and risk-based planning by forcing the team (which includes the business partners) to decide on a subset of requirements to implement during each iteration. Responsible teams will choose features that are the highest priority. (Note the word responsible in that last sentence. Agile practices alone do not a successful team make). Iterations also help the team to "course correct" between iterations of a project if they start going in the wrong direction, or if changing business needs dictate a change in what features are most important.

And while I’ve said this before, I must stress it again. Get the customer / business partner involved. Let them tell the team what they need, and what they want. And, like that voice of reason, the team should sometimes question their needs to make sure they really are needs, and not just a want hidden behind charismatic arguments.

Link: The Interview Question You Should Always Ask

Leave a reply

I ran across this article today, written back in January 2009.  It definitely makes a lot of sense to me, and makes me reflect on co-workers of mine and which ones stand out among the rest.

What would be qualities to look for in a star IT professional?  Here are a few I can think of…

  • They like to read books, magazines or blogs.  This may indicate that they have an affinity for learning.  Apply this to technical articles, and this would make them valuable in helping guide your company toward researching and selecting new technologies or tools.
  • They’re curious about how things work (cars, electronics, etc.).  This indicates that they are analytical and may be good at analyzing designs or project code.

Anybody have any other ideas on what kinds of qualities or extra-curricular activities make up a star IT professional?