Microsoft® VSTS (Visual Studio Team System) is a really cool idea.  It combines a lot of common concerns for a lot of developers, offering a one-stop shopping experience that's really appealing. 

It's comforting for most people to be able to manage their version control from the same interface in which they are making the changes necessitating the control of versions.

It's useful to be able to see what other members of one's team are up to, and tie issues to actual change sets in code (and be able to report on it all).

It's empowering to be able to apply custom check-in constraints to force comments on code changes (or integrate one's own time tracking, as we have done where I work).

But I'm not writing to discuss all these points.  The points above are well-documented by Microsoft® and require no further lobbying from the likes of me.  I like VSTS, to be sure, but there are some shortcomings, in my opinion.

Last Friday was going to be a big day for my team.  We were about to implement a code branching strategy for our version control system, which was needed, but had been badly applied in the past and which was the cause of a certain amount of angst among the senior development staff.  I was in charge of implementing the changes, which included adding a new layer to our folder hierarchy and moving all active development into that folder.  In my experience with version control systems, it is usually an exceptionally bad idea to change the folder structure while there are pending changes in the system, so I sent a preparatory email to the affected developers (a relatively small, manageable number of people) to please resolve their pending changes before I began the update.

When the time came to begin the version control reorganization, all developers had replied that they had no further outstanding changes, and that I was "cleared for takeoff" as it were.  However, being the paranoid person that I am, I wanted to know if anyone had inadvertently forgotten anything that would come back to haunt me and, by extension, my team when the change came crashing down on our heads.  "No problem," I said to myself, "I'll just open Visual Studio and look in the version control add-in for all pending changes..."

I looked for about ten minutes before a quick Google search let me know that, no, there is no UI tool for finding all pending changes in an entire version control repository in VSTS.  There was, however, a command-line tool that would do the trick handily, which I employed, only having to re-type it two or three times to get the arguments just right.  The command-line tool told me, in its understated black and white way, that there were still over 140 pending changes in the version control system.  That was quite a lot, so I quickly sent another email, listing the pending changes and the developer responsible for each, and asking everyone to please have another look (it was getting close to quitting time and it was Friday, after all.  Did I mention I also had a monster head cold?).

I soon got replies from my second round of emails, indicating that, yes, some of our developers had missed some of their check-ins.  This reduced the pending changes by a large number, but there were still about twenty remaining, and no-one was prepared to claim them.  I was now receiving pressure from my manager to get things moving, since he was beginning to worry about his team's productivity on Monday if the change was not made, or if it was only partially complete when the office opened the following week.  "Just undo any pending changes, and let the chips fall where they may," he said.  I agreed, since undoing the changes did not necessarily mean a loss of work as long as the owner(s) of the changes didn't overwrite their local file copies...

"Now, let's see.  I'll go into VSTS and use the Version Control add-in to undo all pending changes." I thought to myself.

"Hm...that didn't work out too well.  I'll try using the Team Explorer; maybe there's a tool in there," I hoped.

Another ten or fifteen minutes' worth of hunting around and another quick Google search later (thanks again, Google), and I was faced with the semi-awful truth: there is no tool in the user interface for undoing pending changes.  "Oh, well," I thought, "this shouldn't be too hard - I'll just use the command-line application to tell the system to undo all the pending changes in my affected project, and we'll be right on track."

I am so naïve...

After a few more minutes, I had found the command-line command for undoing pending changes and crafted what I thought was the correct command to revert all the pending updates in the project I wanted to change.  It was all going well until the command utterly failed.  It seems the 'undo' command requires workspace information (workspaces are sort of like file folders for developers - they can be used to keep track of different versions of the same code simultaneously, for instance).  "Well, dang," I thought, "this is a little more complicated than it seems like it should be, but okay; I'll just get the workspace information from that list of outstanding changes I made..."

Did I mention that I am stupendously naïve?

As you, the vastly more intelligent reader, have almost certainly guessed, the workspace information is NOT INCLUDED with the pending change information.  And thus, the cycle begins again (although this time I didn't even look in the VSTS user interface - just went straight to Google and saved probably ten minutes).  Lo and behold, I learned that there is yet another command for determining workspace names and the identities of the users who own them.  I used that command, and got a list of 72 workspaces our affected developers had created over the life of the VSTS server.  There was no way (that I could find - even after investing those ten minutes I saved) to marry the workspaces to the outstanding changes except to try an undo for each of them.

It is the existence of things like the UltraEdit text editor that make me wonder about the existence of some unifying force in the universe...I urge you all to get a copy, even if you don't edit text files.  UltraEdit has what is called 'column mode' which allows one to make the same series of changes to every line in a text file.  Using column mode against the workspace list I had generated, I made a series of 'undo' commands (one for every workspace I was interested in) and saved that as a batch file, which I ran, finally succeeding in blasting all pending changes out of my source repository, paving the way for me to complete my assignment (which went swimmingly, by the way).

What did I take away from this experience?  If you add up all the time I spent looking around and (re)typing all my commands, I only really wasted about an hour screwing with all of this nonsense (the actual changes I was trying to make took about thirty-five minutes, by the way).  An hour is not a lot of time, and if I had to do this kind of thing a lot, I'm sure I would get faster at it - probably shaving off at least half the time.

So, what am I whining about?

First, I'm trying not to whine (and I resent your characterization).  But the fact is, these operations - undoing all pending changes, listing workspaces and users etc. - are not likely to be things that I want to do frequently.  Since I won't be doing them a lot, that means I'm probably going to have to spend about the same amount of time to research each instance, meaning I am prone to waste more time on this kind of nonsense in the future.

Why aren't there some nice tools in the user interface that I can use?  This question is at the core of my post.  VSTS is such a powerhouse; it can do so much for so many, and yet it is so poorly tooled that it requires a high degree of specialization to effectively administer it.  That degree of specialization is not what I would like my developers to spend their time honing, if I were a development manager.  I would like them to be writing code and making me money.

So, is this lack of simple tools a problem or an opportunity for a cottage industry?  I don't actually know the answer to that question, but it's one I'm thinking about a lot these days.  It's been my dream for some time to own my own small software company, developing useful little tools like the ones that are lacking in VSTS is something that would give me a great deal of personal satisfaction while filling what I believe is an actual market niche, but my reservations are many:

1. How can a small software vendor do developer tools well?  This is a niche that is historically very contentious.
2. Can a small software vendor roll with the market - different VSTS versions etc. - and stay competitive?
3. Is there enough margin for tools like these to keep a small company afloat?

The list goes on...I'll post about my decisions at a later date.  Happy Monday!