More on friendly display names in Work Item Tracking

Buck beat me to the punch in his blog post about our recent design change to support friendly names in Team Foundation Work Item Tracking. I've been meaning to blog about it for the last couple of weeks and hadn't found the time, so I'm glad that he has been able to pass on the detailed post that Brian posted to the forums

This change was a really tough decision for us, especially at this late stage. I feel personally connected to the problem because it was during my visits to some of our partners in the UK this summer that we first began to realize that we had a problem. As you know, we believe very strongly that we should be using our own products internally (dogfooding) because it helps us to understand our customer's pain points, and usually we can catch a huge number of issues that users are likely to see in "real-world" usage. However, in this case it highlights the fact that the way we use our software internally is just one way amongst many.

The customers I visited had very different Active Directory configurations than ours, much greater restrictions about being able to put new machines onto the main internal domains and create new service accounts - and were trying to Team Foundation against the Windows 2000 version of Active Directory because they weren't allowed to create Windows 2003 domains. I guess we all already knew this was the case, but until I'd actually spent a few days with customers and seeing the way these policies impacted their development environements and the way they interacted with Team Foundation, I don't think I had really internalized it. As a result, I think I've now got a much better customer perspective.

So why didn't we just fix this right away? On the surface it seems like supporting aliases and friendly names together should be amazingly simple. Surely we just need to have something in the UI to use Active Directory to translate the alias to a friendly name? Sadly it was much more complex than this to develop (and test) and ends up impacting code across the client and server. What about the interfaces for managing permissions and defining lists of users in the work item type definitions? Or the code that generates the work item changed email notifications? What about our Excel add-in?

This starts to get messy, and doesn't solve the problem properly. Consequently, we needed to change it at the server level - and make sure we make the right changes throughout the codebase, which touched a lot of functionality and would be a big hit for our test teams. However, the consistent customer feedback finally persuaded us that although it was expensive, we needed to do the right thing and make the change - and I'm much happier about the experience our end users are going to have as a result.

Comments

• Anonymous
  December 05, 2005
  The comment has been removed