TFS has a lot of features and a lot of configuration options. What is nice is that all of the parts can be put together to work across the entire development team's workflow and life-cycle. So developers, QA, project managers, Ops, etc all have a part with-in how TFS is intended to function. As a solution, this integration allows for a single solution for various aspects of team reporting, projecting, etc. So rather than having to put together all sorts of different tools for the various parts of development, TFS is a unified package. Like all software development panaceas, there are issues and problems with TFS because it can be a big and bulky thing to administer, train people to work with, get team buy-in, etc. So in some ways, it is better for an organization to grow itself with various tools that have little to no integration with each other for their specific development needs.
Anyhow, I say all of this because I was, not too long ago, brought into a medium sized organization that was using TFS and was asked to evaluate it against other options. What I found for this organization was that TFS was probably a best solution for their particular development process (very much a MS shop) but that they had both a poorly administered system (with most all of the reporting and project management features broken and with almost no direct QA feedback) and developers that were untrained on how to utilized all but the most basic features of the system. What made this audit particularly interesting to me was how the most productive people in the organization disliked TFS while most others were either indifferent or liked TFS because they had figured out how to game the few features that worked. So, yeah, in that case, TFS was "beyond terrible."
TFS is not a solution I would run in a recommend wholesale but it has a lot of nifty if you look under to hood.
Or maybe you think that TFS is visual source safe and well, that wasn't too great.