Merge and Goto Sadness

Almost two months ago I went off on my own branch of the source tree to make some restructuring and refactorings. Wednesday I finally finished my changes (or, got them close enough to begin bringing them back into the trunk) and am now in the process of merging. I found a pretty sweet tool for performing individual file merges named Guiffy. It's a $75 tool, but is free for 21 days (which should be more than enough time for my process). The critical feature it provides is character-by-character diffs. Given some of the changes I've made, this is huge. It also seems to be pretty good about correlating changes that effect line numbers. It's not perfect, but certainly good enough.

While merging, I came upon a statement that made me really, really sad. C# supports goto statements?!?!? I thought that goto had been recognized long ago as a bad idea. What gives?

Working with XBAP

When running an XBAP from within Visual Studio 2005, there are some caveats. If you want to be able to debug the XBAP you need to run VS NOT as an administrator. In addition, you cannot be running any other IE processes.

If you do run as an Administrator, the XBAP will not automatically reload between runs. To get it to reload you need to clear out the application cache. Run the 'CMD Shell' application (part of the Windows SDK) and enter:

mage -cc

This should cause your cache to be cleared, and the XBAP should reload with any changes the next time you run.

First Week

My first week here at Agile I've been working on a few different things. First, I've been digging into the Huddle code base. I brushed up on the basics of WPF and even wrote a simple application in XAML before starting last Monday. Now I get to dive in head first to, basically, every feature WPF offers. Along with that I will need to learn WCF. C# is close enough to Java that the transition is looking to be straight-forward. Separately from getting to know the Huddle system, I have been investigating issue tracking systems.

TRAC looks to be a decent system for tracking issues, but I know there are better systems out there. At UNL I used a system named Jira, by Atlassian. Compared to TRAC or Bugzilla, it is a joy to use. Managing issues, tracking change history, and generating reports is super-easy. Jira also has a nice dashboard portal value-add that is useful for viewing the overall progress of a project. It gives a nice '50,000 ft' view from above look at a project (or projects). One thing that we never got into a UNL is workflows.

Pretty much every issue tracking system has some notion of a workflow. This allows the development group to lay out, in the system, their process for doing work. In practice, a workflow may look like the following:

1. A tester discovers a bug, and creates an issue. The tester isn't sure exactly who the issue should be assigned to, but the workflow would auto-assign it based on the component. In addition to auto-assigning the task, the workflow auto-assigns a tester who is in charge of that component.
2. The issue is automatically assigned, and the assignee developer receives an e-mail notification.
3. The developer finishes his other tasks, and is finally ready to begin work. He marks the issue as 'in progress' and begins work.
4. When the developer feels the issue is completely resolved, he marks the issue as 'resolved,' which then sends an e-mail notification to the tester and assigns the tester as the new 'owner' of the task.
5. The tester runs through and discovers that the bug isn't totally finished, so she marks the issue as 'reopened'. Again, the developer gets an e-mail and is auto-assigned.
6. Steps 3-4 are repeated, and this time the tester feels that the issue has been completed. She marks the issue 'closed' and the process is complete.

That is a pretty average case scenario for how work might be done, but the workflow automation allows each person to focus on his/her work without having to coordinate with the component developers to know who is best able to resolve the issue. This also prevents an overall manager from having to intervene and delegate issue assignments. As teams grow, minimizing the need for constant communication is going to become more and more important.

I've been evaluating several different systems for managing issues. The most important attributes I have been looking for include:

• Web Access - a lot of the systems have a Windows client, but web access is convenient
• Requirements Tracking
• Test Plan Management
• Customer Access features - this comes in a wide variety of flavors
• SVN integration - I think this is pretty important
• ActiveDirectory Authentication - most of them support LDAP authentication, so we should be good there
• VisualStudio .NET integration - this would add a lot of convenience
• Ability to import existing TRAC tickets - I think some level of import would really ease a transition from TRAC to the new system

I have been spending more time on this investigation than I originally intended. I think that, if we are going to move to a new system, we should do it while the team is still very small. The need for a more formal process is going to grow with each new hire.