TFS checkout lock best practices

Question

I'm having difficulty convincing others in my organization to stop indiscriminately locking files on checkout. Any ideas where I can find an "official" document explaining why a checkout lock should be used sparingly? Microsoft recommends:

As a best practice, use the Lock type option with discretion and notify your teammates why you are locking an item, and when you plan to remove the lock.

but does not go into any details.

Anything that I could point to would be very helpful.

Answer 1

Although I don't have an official Microsoft source, I'm an MVP in Application Lifecycle Management, so hopefully that's enough to make this compelling. :)

Locking text files (i.e. code) on check-out can be a massive impediment to productivity. I've seen it myself when I was working at a time a co-worker wasn't, and they had an exclusive lock on a file. All of a sudden, it's thumb-twiddling time. It's even worse when you're trying to troubleshoot or fix a time-critical issue.

The most common reason why people want to lock a file for exclusive editing is because they don't want to have to perform a messy merge later on.

That is usually symptomatic of one or more things:

• The files being exclusively locked are too big (one file with lots of classes in it, a "god class" that does too many things, etc). The resolution for this problem is to refactor code into smaller, more isolated classes according to the Single Responsibility Principle. Or, if you absolutely must, and you're working in the .NET world, abuse the partial keyword to split the same class up across multiple files, although I want to go on the record and state that every time I see this in a codebase it makes me cry a single tear of infinite sorrow.
• The files being exclusively locked are in the midst of major, long-term refactoring. The solution here is to isolate major changes within branches, with frequent reverse-integrations of changes from the trunk back to the branch.
• The person doing the change just doesn't like merges. I can't help you with that one. If you're holding onto code without committing it for a long enough time that a merge is going to be painful, you're not committing your code often enough. If you're not committing your code because it's not done yet, but the change is ongoing and you don't want to interfere with others' work, then you're not using branches properly.

Can there be times when exclusive locks against code files are good and useful? Probably, but I can't think of a problem that it addresses that can't be addressed by using other, more appropriate source control features.

Use Local workspaces if you can, since they don't enforce exclusive locks.