Wednesday, January 09, 2008

Even when your right, you might still be wrong.

Even when your right, you might still be wrong, or not.

I had an interesting experience back in December. One of the Product Managers was responsible for taking an out of date spec and updating it to reflect the current product. She sent out a SharePoint link to the Functional Spec she wanted reviewed.

There were tons of errors and it looked like she had only made some cursory changes. I decided to give up reviewing the spec and I sent her a quick email that said her spec was still very out of date and that I only got halfway through the document.

Here is the email thread after my first email:

--------
PM:
I’m not sure you read the right spec. I’ve now spent all day correcting issues in yours only to realize that the version TFS that I put up on Friday afternoon had more stuff in it than the one you commented on.

ME:
I double checked that I am using the correct spec. SharePoint has a history option for documents and you can see what changes were made, by who and when they were saved.

The link you sent ( also in this thread ) is the one I commented on. It was added to Sharepoint by you Friday 12/14/2007 at 3:26 PM.

I downloaded the file again (this time to a new location) and manually walked through every single comment I made to make sure the text I commented on was the same in the linked document you provided. Everything is the same.

I am not sure what document you are working on, but it is not in Sharepoint at the link you sent out. Maybe it is a local copy?

Please come see me if you have any other questions or need me to walk through what I did.

------------

So this looks cut and dry right? I clearly documented the version of the document I was looking at and all my ducks were in an order.

The conversation continued, in email and then in person. She was positive I was looking at the wrong version and I was positive that I wasn’t. When I went up to her desk to walk her through what I did, I ran into a problem.

The SharePoint history for that document no longer matched what I had seen only 10 mins before. The 12/14 version I had referenced now said 12/13. This confusion only reinforced the PM’s belief that I somehow downloaded the wrong version of the spec.

I was baffled. I knew what I had seen, I had double checked. What could have happened? I went back to my machine and luckily I still had the SharePoint window open and I could clearly see that I was not crazy. In the following screenshot you can the same document (notice the GUID in the URL) had mysteriously changed dates and timestamp.

It took me about 30 mins to Google and troubleshoot the issue, but the conclusion we came up with was that she had checked out the document, made changes and never checked it back in. So when she sent out the link it still pointed at the old version.

This turned out to be a known issue/feature with SharePoint that has tripped a few people up.

This was a good reminder to me to always approach any contentious issue with an open mind. If you respect the person you are talking to, there is likely a good reason they have formed a differing opinion and you should always be aware that things my have changed, even in the time it takes to walk over to demo something.


Wednesday, January 02, 2008

TFS – So many ways to screw yourself, so little time.

Part 1: The Rant

My new company implemented TFS about 6 months before I took over the QA Department. Unfortunately I had no say in the setup and subsequent customizations that occured. While I am sure everyone had the best of intentions the end result was a nightmare.

The original plan was to take full advantage of TFS; Sharepoint, VSS, Iterations, Tasks, Requirements and Bugs. They were even going to migrate all existing requirements from Word documents into TFS and link everything up to Tasks and Bugs.

Sounds like a solid plan, with a little hard work and planning, what could go wrong?

Unfortunately this major shift in process was treated like a skunk works project. One QA guy put together a sample installation, got approval and then worked with the Dev team to set something up.

My opinion of the whole adoption phase was that everyone was focused on hammering out (on paper) a series of workflows that felt familiar to what they were used to using. And then when time was running out they tried to hammer custom workflows into TFS.

Here are some of the decisions that were made:

  1. Heavily customized the CMMI process template.
  2. All workflows modified
  3. Added new fields and changed the meaning of existing fields
  4. Created custom triggers to enforce a very complex 'Assigned To' scheme (Dev, QA , Business)
  5. Created a single TFS project, using the company name, then created sub projects (using Areas) under that one project.
  6. Placed all code under a single VSS branch, created one giant build for all code.
  7. Ignored the recommended SharePoint setup and created a custom hierarchy of projects to store documents in.
  8. After about 3 months of use they switched the layout around, so now there are ‘historical’ documents in an old area and newer documents in the new area.

Here is the current state:

  • Product Managers pulled requirements back out of TFS into new word documents because TFS was too difficult to use.
  • Bugs are tracked and assigned to developers using a spreadsheet with TFS IDs.
  • There are functional bugs inside TFS with the custom 'Assigned To' workflow logic that was added.
  • All of the default Reports were broken, new reports have not been able to be created due to the complexity of the changes.
  • TFS is used only to store code/documents and file bugs. Requirements and Tasks are no longer tracked in TFS.
  • Everyone thinks TFS sucks are are 100% resistant to making changes or trying to fix the issues.

So this is the problem that I have to fight the unpopular fight to fix. When I get some time I will blog about my proposed solution (I do have one that I am working on) as well as track my progress.