If your dev computer has 500GB of disk space taken up by 237 branches of the same code even though 99% of the files in those branches are identical… you might be using TFS.
If you spend 45 seconds watching a little spinning icon each time you rename a file… you might be using TFS.
If your supervisor requires that you log your time in 15 minute increments and track those increments against work items in your current sprint… you might be using TFS.
If the workflow for tracking a bug fix requires a simple 27 click process that includes setting values in 3 different status fields and manually reassigning the work item and still doesn’t map to your actual process… you might be using TFS.
If the most productive team in your company manages their sprints in Excel instead of the company standard ALM software – and you wish you were too… you might be using TFS.
If creating a new branch requires more than 10 seconds… you might be using TFS.
If you ARE NOT CONFUSED when you hear people say things like “It took me 5 minutes before I was able to switch to disconnected mode” or “I spent a full day trying to fix a corrupted workspace”… you might be using TFS.
If you’ve ever heard the phrase “Yeah it’s kind of inefficient and it has some rough spots and the constantly connected model is a pain, but it’s sooooo much better than Source Safe”… you might be using TFS.
If you’ve ever lost 2 days trying to fix history after a bad merge… you might be using TFS
If your company has ever sent all of the devs home because the source control server was down and nobody could work… you might be using TFS.
I find it tragic that so many .Net teams use what I consider to be the “worst of breed” solution just because it’s made by Microsoft. TFS is a cumbersome, poorly designed system that extracts a productivity tax on every developer, every day that they use it. The constantly connected model alone is reason enough for me to never use this tool. So why do people use it if it’s so bad? I think it comes down to 3 unfortunate facts of life:
1. SCM (Source Control Management) and ALM (Application Lifecycle Management) software is typically selected by managers, not by the developers who will need to use those systems.
2. Microsoft makes TFS. It’s a safe choice. Nobody is going to get fired for picking the solution made by Microsoft.
3. Most of the teams using TFS have either never used another SCM, or were previously using Microsoft Source Safe, the only SCM so horrible that it actually makes TFS look good by comparison.
So the next logical question is “Ok Mr. Complainer, if TFS is so bad what do you use instead?”
I’m glad you asked. In my opinion there is only one choice, git. A git repository hosted on either Bitbucket (from Atlassian) or GitHub, and managed using SourceTree (also from Atlassian) is such a gloriously simple and low friction solution that I’ve never found cause to use anything else. If you find yourself in the position of picking an SCM, do yourself a favor and try the git/SourceTree/(GitHub or Bitbucket) solution first and see if it meets your needs.
ALM/sprint planning/bug tracking is another matter. There are lots of SAAS apps that provide this functionality and I find all of them easier to use than TFS. GitHub itself has some basic ALM functionality that will be good enough for most small teams. There are also 3rd party SAAS apps that plugin to GitHub or Bitbucket to provide additional features. Huboard is one such app that provides a Kanban board for your issues on GitHub. The bottom line is try something simple and see if that works for you before moving on to a more complex solution like Jira or (shudder) TFS.
One last thing. I know some people will read this and say “You’re totally out of touch, you can use git as your source control within TFS, get all the git advantages, and still get all the great TFS vertical integration.” That might be true. I’ve never used TFS with git and I’ve never seen it used in any of the TFS shops that I’ve worked with. That’s worth noting. I’ve heard a lot of people talk about TFS with git, but I’ve never actually seen it implemented in the wild. So, it might be the land of milk and honey. It might fix every problem I’ve ever had with TFS. I doubt it, but it is possible.
To conclude, I don’t have an informed answer to the TFS with git question because what I’m doing works great and I’m not willing to invest another iota of my precious time into the sinkhole of productivity that is TFS. I think the great philosopher Samuel Jackson (Pitt) from Pulp Fiction said it best. “Sewer rat might taste like pumpkin pie, but I wouldn’t know, because I wouldn’t eat the filthy mother-scratcher.”
Awesome post. Couldn't agree more. TFS vs Git is like comparing a tractor with a sports car. TFS has it's advantages though. That is why I still use it for my own projects.
ReplyDeleteif your clients submit change requests online, your project manager assigns it to a developer, the developer does the implementation and associates the request to the check in, the developer then kicks of a build on the build server, which packages the build ready for deployment and generates complete release notes, all in one system, then you are using TFS and you laugh at people who think they know better.
ReplyDelete