Sometimes when customers report issues that we knew about but decided not to fix, we end up thinking “Why did we just not fix that bug?”. I came across one such bug in TeamBuild a few days back. I took this as an opportunity to think about why some small but nice to have fixes don’t tend to make it into the product.
Bug: The customer was getting an error during build - “The working folder C:\Builds\somepath\Sources is already in use by the workspace WSName;DomainUser on computerName”. The error message gave him enough information to figure out that he needed to delete the workspace though it wasn’t clear why he had to do that. Also figuring out how to delete the workspace especially when the owner is a non-domain account like “Network Service” is painful.
Repro scenario: This issue commonly happens when the TFS build service account is changed. It is also possible that someone manually creates a workspace to map the same folder as used by TeamBuild for the build directory but this is definitely rare.
TeamBuild creates a version control workspace on the build agent to sync the sources to a local build directory before doing the build. As part of the build process, TeamBuild checks to see if the workspace already exists, and deletes or reuses it if it does. But TeamBuild only checks for workspaces for the current build service account. That is why if a user changes the build service account after a build is run, we see this error.
This has been the behavior since the first version of TeamBuild and in the last 2 releases this behavior has not been updated.
So why did this bug not meet the FIX criteria?
Generally at the beginning of each product cycle, the team comes up with new set of features we want to include in the next release based on user input, market research, overall product goals etc. This bug doesn’t qualify as a feature, so it would go on a backlog or wish list of small changes we would like to make. The team then goes heads down into development and fixing bugs in the new features.
As we get towards shipping the product, a set of criteria are used to figure out if a bug should be fixed or not, some of which are:
1. Does it block a high priority user scenario?
2. Is it is regression from a previous release?
3. Is there a reasonable workaround that is easy to apply?
4. What is the cost/risk of fixing the issue?
5. Would it cause customers lot of pain?
This particular bug would have been low risk and easy to fix but not many customers are complaining about it and there is a simple workaround available. So it never made it above the cut line in the wish list.
If there are other issues like this which you would love to see fixed, please do let us know what they are!