Team Foundation Server is the Lotus Notes of version control tools
tl;dr: Advocates of Team Foundation Server, Microsoft’s ALM suite, respond to criticism by saying that TFS is not just source control but an end-to-end integrated ALM suite. This completely misses the point of our criticism of TFS in the first place: that we find it restrictive, bureaucratic, unreliable, and extremely difficult to use. End to end integration does not justify unreliability or a poor user experience.
About a year ago, Martin Fowler conducted a survey of ThoughtWorks developers to find out what they thought about various source control tools. Not surprisingly, Git came out top. The one that came out bottom? Team Foundation Server. In fact, TFS was unique in getting no positive responses at all: out of 54 respondents who had used it, every single one of them rated it as either “problematic” or “dangerous.”
Team Foundation Server advocates claim it’s unfair to compare TFS to other source control tools, since it’s not just source control, but an integrated end-to-end application lifecycle management solution. Comparing TFS to, say, Subversion, is like comparing Microsoft Office to Notepad, so they say.
Now where have I heard something like that before? Oh yes, Lotus Notes:
The main focus for frustration is Notes’s odd way with email, and its unintuitive interface. But to complain about that is to miss the point, says Ben Rose, founder and leader of the UK Notes User Group (www.lnug.org.uk). He’s a Notes administrator, for “a large automotive group”.
“It’s regarded by many as an email program, but it’s actually groupware,” Rose explains. “It does do email, and calendaring, but can host discussion forums, and the collaboration can extend to long-distance reporting. It will integrate at the back end with huge systems. It’s extremely powerful.”
The thing is, it wasn’t the detractors who were missing the point. It was the Lotus Notes guys. You see, e-mail is right at the heart of any groupware application. It’s the part of the application that users interact with the most. It’s where usability matters the most. And it’s what Notes got wrong the most.
It’s exactly the same with ALM tools. Source control is the part of your ALM tool that is most visible to developers. It’s source control rather than, say, work item tracking or continuous integration, that can make or break your workflow. It is source control where a zero-friction experience is most important.
Team Foundation Server is not zero-friction. Not by a long shot.
I guess if you have only ever used TFS, Visual SourceSafe, and perhaps exclusively trunk-based development in merge-paranoid Subversion teams that use if statements and configuration settings to avoid branching, you would be happy enough with it, since that’s all that you know source control to be capable of. But once you’ve actually used one of the alternatives that offers you fluent, unrestricted branching and merging, a local sandbox, flexible workflows, self-consistent best practices, and source control as an extension of your undo button, the limitations of TFS become so massive that it’s not even funny any more. (Incidentally, if you tot up the figures in Fowler’s survey, you’ll find that his respondents had, on average, experience with six different tools.)
But even if you’ve never used a DVCS and are only comparing it to Subversion, it’s still a usability disaster. Subversion may have pitfalls and gotchas and limitations of its own, but once you know your way around it, you can at least work as fluently with it as is possible with a primarily trunk-based, centralised tool. In TFS, even the simplest tasks become Herculean undertakings. How do you back out a changeset that isn’t the latest, for instance? Why can’t I have a check-in screen that shows only the files that have actually changed since my last commit? Why does it take me half a dozen mouse clicks for each file in my check-in screen to find out that it doesn’t have any changes? Why is it asking me to check in files that don’t have any changes in the first place? Why does it turn Visual Studio into a Berlin Wall around my code with these awful read-only files? Why does it lobotomise the branching and merging experience with baseless merges, making feature branches — pretty much a must-have for a pain-free ALM experience these days — impractical for all but the largest tasks? Why can’t it cache my login credentials to a server on a different domain like Subversion does? Why does the command line interface bring up dialog boxes? Is it a command line interface or isn’t it? And that’s barely scratching the surface of its usability problems. It doesn’t even have a search tool to speak of.
Furthermore, the source control component is the one part of TFS that you can’t swap out for something else. You can use TFS source control with Trac, Mantis, FogBugz or Jira, or with TeamCity or FinalBuilder, but you can’t use TFS work items or TFS build servers with Subversion, or Git, or Mercurial. As far as TFS is concerned, source control is their way or the highway.
End-to-end integration is all very well, but it is hardly a killer feature, and when the most visible component that it integrates is difficult to use and gets in the way, it ceases to be an asset and it becomes a liability. It’s far better to have a selection of separate tools, each of which is designed to do its job well, than a single monolithic application that does everything badly.
Posted at 08:00 on 14 February 2011.
Excellent post. I haven’t seen an in depth explanation like this before. #git is the best system out there and I don’t find integrating other tools with it as the Microsoft FUD machine would likeus to believe.
Meant “as difficult as”
I happened upon your post and didn’t know about the survey. It’s interesting, but I must say that the anti-TFS results are not surprising, given the demographic. My guess is that all the pro-TFS guys were employed at the time the survey was given. The giveaway is that the “respondents had, on average, experience with six different tools” and unemployment offers lots of learning opportunities.
I’d question any workflow or set of practices that requires branching, merging, and certainly baseless merging to be the norm. Most teams I work with don’t have the issues you mention because they do things in an organized, repeatable way. They are professionals. They don’t implement flexible workflows. They don’t check out files they don’t intend to edit. They don’t back-out changesets as a practice. They don’t use the command-line tools unless they have a compelling need. They focus on using the integrated tools and delivering business value. Team Foundation Server, when used by a properly trained team, assists them in doing that.
You’ve got some valid points in here on usability. Each iteration of TFS gets better. Each iteration gets further away from feeling like VSS. You’ve also got some misinformation in here and, either you were improperly trained, or you just intended to do a hatchet job.
Nice credibility attack alm dude. Posting anonymously is a nice touch. I wouldn’t want to admit these silly opinions with my name attached either.
In reaction to ALM guy: kind of a condescending reaction, don’t you think? Saying that having experience with multiple tools == unemployed?
I’m responsible for managing a *large* TFS 2008 instance. Recently, we decided to migrate away to Git because TFS simply won’t work in an agile environment (not to mention all the bugs). I’ve personally witnessed a lot of the issues James described (and even a few of my own).
True enough, if you only do trunk-only development, not bother with branches and don’t care that you cannot easily remove commits from your history, TFS will probably work for you.
You call the workflow above ‘professional’. I would call it ‘working around the tool’.
@ALM Guy: I can’t seriously believe that you’re describing ThoughtWorks employees as “unemployed”. These folks are widely regarded as some of the best ALM experts in the world. They include leading luminaries in the agile software movement. They get their experience of multiple SCM tools from working with large, international clients. If I wanted anyone’s opinion on Git versus TFS, they are the first people I’d ask.
@Adam: original poster set the ground rules, tone. What’s FUD stand for BTW?
@Wilbert: ever heard the term “jack of all trades, master of none”? Also, I’m curious why you think TFS won’t work in an Agile environment? Please point me to a blog post or something. I’m also curious why you consider removing commits from history professional? Perhaps transparency and traceability are considered bad on your team?
@James: alles klar! the survey was just for ThoughtWorks employees. The demographic just became even more clear. I hope I don’t have to explain to you that luminary != practitioner or Agile expert == ALM expert. I’ve met dozens of Certified Scrum Trainers (CSTs) over the years. They are considered the Jedi knights of Scrum (the most popular Agile method out there). Most don’t know beans about ALM. My opinion is that ThoughtWorks is much more cross-functional than a group of process ninjas, but the anti-Microsoft tone from that group and its ilk over the years has been predictable and not always backed-up by truth.
My goal here was to get your attention and suggest that you start implementing the iKnowWhatImTalkingAboutBeforePosting interace and ditch the iMicrosoftFUD one, or at least override the methods that @Adam tunes in for.
@ALM guy.
See http://walkingthestack.wordpress.com/2009/10/02/team-foundation-server-issues-%E2%80%93-part-i/ and http://walkingthestack.wordpress.com/2010/02/09/team-foundation-server-issues-%E2%80%93-part-ii/ for some concrete examples.
I have more, but the comments only allow max two links.
You can also reach me at twitter @wdolleweerd
Still posting anonymously? Fear doubt and uncertainty is an old crude sales tactic that I personally witness microsoft using to “market” tfs. They set the tone. In doing so, I’m quite happy doing the same. Going into a shop that has large teams successfully using git and forcing them to use tfs is nasty sales tactics. And this is all it is for microsoft: sales. It has nothing to do with best practices. let the koolaid wear off and see how other more healthy communities work. There are other things microsoft does well. Tfs is not one of them.
lol, ALM guy’s comments just made my Thursday morning. Thanks.
@ALM Guy: I suggest you follow your own advice (re: iKnowWhatImTalkingAboutBeforePosting). If we are ignorant, as you claim, then please shed some light for us. Please explain why branch-per-feature is an anti-pattern (a claim you made, though not in those words).
Also, I know I would to know why you feel TFS is superior to other tools — especially in the source control department — since you seem to dismiss (out of hand) the claims of ThoughtWorks and Martin Fowler.
I think if you are going to compare to Lotus Notes you should probably use something a bit more recent then a 5 year old article which is horribly out of date.
@Chad Myers – You seem level-headed so I will give it a shot. First, I would need to know more about the product, the team, how the team works, its size, how often and how it synchronizes with other teams, how often and hot features are synchronized with other features, the team’s promotion model, the product’s release cycle, etc. To assume that a team should be branching by practice and not by exception leads to inventory (yes, ALM can generate technical debt) and the eventuality of needing to merge. Merging sucks. I’m sure we all agree on that. Teams shouldn’t adopt a branching model because it’s cool or because people blog about it.
I’ve seen good practices such as dev/test collaboration, CI, automated testing harnesses, and test impact analysis alleviate the need to branch. Training may be required for these individuals as well. Branching is not a silver bullet, even though the new, hip DVCS tools make you think so. In my experience, it’s a smell of an ALM dysfunction. That said there are plenty of valid reasons to branch.
As was stated in the original post, TFS is an ALM tool. It’s more than just version control. When used correctly by a trained team with a good process and development practices, business value can be measured and traced end-to-end, with little to no friction. What people miss is that the data warehouse is where the money is. The other systems listed in the survey don’t have that. They don’t serve the product, only the team … and hobbyists.
Advice followed.
@Si: I’m aware that the article is an old one, and things have undoubtedly improved since then, but Lotus Notes still has a long-standing reputation for historically poor usability of its most visible functionality, and my point was simply that Team Foundation Server still suffers from exactly the same problem. Source control, after all, is the most visible component of your ALM suite, and it is the component that can have the biggest impact — positive or negative — on your workflow.
@ALM guy: Actually, we don’t all agree that merging sucks. DVCS users have no problem whatsoever with merging. That’s why people get so excited about branching and merging in the cool new DVCS tools — they actually make merging work. The concept of a baseless merge is totally alien to DVCS: they can find a common origin for branches that are fourth cousin twice removed if need be. And they make it so easy and intuitive that there’s much less of a need to send your entire team on expensive training to use it properly.
You’re still not clear what exactly it is about frequent branching and merging that you think is an ALM antipattern. Yes, you can run into trouble with branching and merging in a DVCS if you do things wrong, but the problem usually isn’t branching and merging per se, but other issues such as poor communication with the rest of the team, spaghetti code, and disregard for coding conventions etc, that increase the risk of merge conflicts, and you soon learn where the problems lie and how to avoid them.
In actual fact, fluent branching and merging has many other benefits. You can commit much more frequently than before, which allows you to separate your work out into bite-sized chunks that are easy to describe in a commit summary and make it easy to see what’s going on when you have to look back at your history to find the revision that introduced a bug. Local versioning gives you a sandbox where you can prepare a series of revisions before integrating them with the central repository. In effect, you gain the concept of source control as a persistent, project-wide undo button — and when you lose that, it hurts.
I appreciate that TFS is an end-to-end ALM tool, and the other tools listed are only source control. However, you can add into the mix a CI server such as TeamCity, an issue tracker such as FogBugz, Jira or Mantis, code review tools such as Kiln, and so on, and these provide the end-to-end traceability that you get in TFS, only they do it better because they are each specialised for the job, rather than being a jack of all trades and a master of none. In fact, I’d like to try out the TFS work item tracking and build tools with Mercurial as my source control, but TFS just makes this unnecessarily difficult and cumbersome because of its over-tight integration.
Finally, I must take issue with your statement that “the data warehouse is where the money is.” This is incorrect: working software is where the money is. This is recognised by one of the twelve principles of agile software development: “Working software is the primary measure of progress.” In fact, some metrics themselves can be an ALM smell, such as SLOC per day for developer productivity, which just encourages (if not requires) us to bloat our code base with gratuitous copy-and-paste code that is hard to maintain and support.
Funny how an MS Alm guy is not familiar with FUD. sigh.
I believe FUD “resolves to” TFS.
I like this thread but there a few things I would like to add.
The analogy with Lotus Notes is quite interesting. When Notes first came out in the early nineties, it offered a single interface to view email, wiki like functionality, intranet like functionality, the ability to (fairly) easily create bespoke applications, all with good search functionality. Which in the early nineties was even cooler than MC Hammer. There was no other single product in the market at that time that could do anything close to this but there were lots of smaller apps that could fulfil all of the above with a much more pleasant user experience. However, one tool was perceived as much more efficient for large enterprises and in those IT voodoo days it clearly was . So actually Notes started very well but got quickly overtaken. Although TFS has parallels in that it attempts to provide broad, integrated functionality, it is certainly not getting overtaken. It used to be really really bad.
The point that I think ALM guy (can you believe he posted something anonymously?) was trying to make was that TFS has the potential to offer much more than the sum of the separate tools but this depends on your project, your resources, your experience and many other variables. Interestingly, all of the comments apart from ALM Guys’ seem to be from a development viewpoint. However, MS claim that TFS provides functionality and information to a wildly wider range of stakeholders than mighty developers. I am sure if you asked a group of PMs, BAs or Business users what they thought of TFS compared to other tools they had used (for their specific needs) then you would possibly get a more favourable view towards TFS.
This leads on to the statement “It’s far better to have a selection of separate tools, each of which is designed to do its job well, than a single monolithic application that does everything badly.” Which is obviously true – why would you want a tool that does everything badly? But TFS might have significant flaws but it does not do “everything badly”. We know that TFS is far from the best source control product but do the other pieces make up for it or indeed the value of the integrated environment? So then it just comes down to a trade off. The agile mantra of the most important thing being ‘working software’ does not wash here – this is a development-centric view. If the tool causes Dev some friction but offers the business much more value through governance or project planning or whatever then it’s the way to go. And of course, the opposite is also true.
I can understand that PMs, BAs and so on would like TFS for its reports and so on. And maybe I was wrong to say that TFS does “everything” badly.
But — and it is a big but — the one thing that it does badly is the one thing that has the biggest impact on productivity of your team. Source control done right can enhance your developers’ productivity. Source control done wrong can crucify it.
In a software team, it is the developers who actually build your product in the first place. And it is source control, more than reporting, or end to end integration, or anything else, that can make or break your developers’ productivity.
Let me put some figures on this. TFS gives you end-to-end integration and reports for your business analysts, all within Microsoft Project. FogBugz doesn’t give you the same level of end-to-end integration, but you can still get all the reports and governance you need through your web browser.
Now, do you really think that letting your PMs use Microsoft Project rather than their web browser is worth £150 per PM per day?
I’ll explain where I get that figure from. Let’s say you have a number of Scrum teams, each consisting of six developers and one PM/BA. Your average developer salary in London is about £45K or so. That means that if your TFS server goes down for one hour, you have just wasted about £150 in terms of salary bills alone. If one developer takes six hours to check in some code thanks to a gated check-in policy, you have similarly just wasted £150. If there is just enough friction in daily use for your TFS team to take seven hours to do what a Mercurial team could do in six, you are likewise wasting £150 per day.
Ask any developer who has significant experience with both Mercurial and TFS, and you will be told that I have most likely underestimated the difference in productivity here.
First I would like it clear that I am not a massive advocate of TFS (although I do have a soft spot for early Notes!), I just like a fair debate. So to deal with your responses.
You do not need MS Project at all to leverage the ‘governance and reporting’ benefits of TFS. You use a browser or excel – which I am assuming everyone has.
Why would your TFS server go down? It’s a Microsoft product and therefore, it’s more easily handled by your infrastructure guys who like to support Microsoft products rather than open source apps. These days, there is no reason at all why TFS would be less reliable in terms of availability than any other product.
Why would a developer have to wait 6 hours for a gated check in. You can configure TFS to apply whatever workflow you want including check in policies blah blah. So you can decide what process is most efficient for the development team (and maybe the other stake holders?) and implement that. At least you have the choice?
I would struggle argue about the source control comments but I will say that you can make TFS very lightweight, if you like and TFS 2010 is, dare I say it, alright in terms of source control. But you are then paying a lot for not much if that is all you are using it for. The integration with VS is not to be under estimated. I think you could possibly argue some sort of productivity saving in favour of TFS there.
In terms of money, let me give you a financial example that goes beyond just a developer being impeded. Imagine you have a big project to deliver and its all getting a bit stressed. We have all been there. As your requirements and reporting are not as integrated as they could be (with TFS), one requirements does not fully get tested because it’s a bit different to what you normally do and it falls down a gap between one of the separate tools you use for requirements, project management, architecture, security, build, testing, etc. This could then lead to, maybe, a fine from a regulator of several million pounds. A ridiculous example I know but you need to trade off the developers productivity against the risk or business value. TFS could (if implemented correctly) support all of these activities outlined above. Its integrated environment and ability to enforce certain processes (such as a check in gates) does reduce risk. It’s trade off. But you were all far too callous to dismiss ALM guys comments so quickly.
I guess the point I am making is that “developers productivity” is not the be all and end all for the business that you work for?
p.s. Do you know you have a cat on your shoulder?
I don’t think your example is ridiculous — it’s just very vague and nebulous. You’ll need to give some specific real-world examples of how TFS’s end-to-end integration reduces risk compared to, say, FogBugz, TeamCity and Subversion. You’d also need to show that the reduction in risk is worth the hit to developer productivity incurred by TFS. As far as I can see, the TFS ALM folks overstate the advantages of end-to-end integration, downplay the impact of its abysmal source control on developer productivity, and exaggerate the risks of the alternatives, especially when it comes to branching and merging.
Incidentally, the figures that I gave were based on some real world examples in multiple organisations. (See this tweet and this tweet for instance.)
Finally, I’m a bit bemused about your comment about TFS not being overtaken. Some of the features of modern DVCSs leave TFS looking like something out of the late Cretaceous. As I’ve said several times before, you can use Git or Mercurial not only as source control, but also as a project-wide, persistent undo button — and that is an amazingly powerful feature. You can shelve or revert not just whole files but individual changes to files. And that’s before I even get started on concepts such as rebase, bisect, and easy branching and merging.
I feel quite please that I have managed to write a staement that is both “very vague and nebulus.” Is very vague more unclear than nebulus?
This is getting less fun. But I do feel quite please that I have managed to write a statement that is both “very vague and nebulous.” Is very vague more unclear than nebulous?
Maybe the ALM folk do over state the advantages of TFS but your argument does not deal with this. Maybe the other people over state the alternatives. As I said, it’s a trade off. And to work out what’s right for you then you need to do some proper research. I would favour a more scientific approach rather than looking at tweets from people clearly not keen on TFS. I would also suggest that you think beyond the realm of the developer.
Almost done. “Bemused with my post”. Yes right. That was the one before last so it must have really bemused you. Lotus Notes was great then turned rubbish. VSS was really bad but TFS 2010 is alright. I would say that the Microsoft offering, in terms of source control has improved more than most of its peers, although this could be because it started so far behind.
By “vague and nebulous” I just wondered if you could pinpoint any specific areas where a lack of end-to-end integration could cause problems with regulators, auditing etc.
Incidentally, which source control tools/ALM suites have you experience with? I find that in general, people who argue in favour of TFS tend not to have much significant experience with anything outside the Microsoft (TFS/VSS) ecosystem.
“Source control is the part of your ALM tool that is most visible to developers.”
“It is source control where a zero-friction experience is most important.”
Source is key but ONLY from a developer perspective. Should a PM care about it? no. They want zero-friction task management. What about project owners, scrum masters, analysts etc…
The reason people shouldn’t compare TFS vs others is not because TFS does more, but TFS users are not just developers and comparing from a developer only perspective is a problem.
You bring up a lot of valid points that the source control lacks, but ALL source control systems lack features that someone somewhere wants.
Missing feature: For example in GIT how do I do a gated check-in on ALL developr machines?
Friction: Unless I setup a centralised server and complex hierarcy (like what is done with the Linux guys) where is the version I run my tests against?
That missing feature and/or friction are just two examples of things that may cause someone to avoid GIT. That doesn’t make GIT bad, just not correct for that persons needs.
At the end of the day, use the right tool for the job. Sometimes that is DVCS like GIT and sometimes that is TFS.
Looking at two non source issues you bring up:
“Why can’t it cache my login credentials to a server on a different domain like Subversion does?”
That is possible, use Windows Credential system for that.
“Why does the command line interface bring up dialog boxes?”
This is a problem because of? You are in Windows, you have a GUI so what is so wrong with using that? GIT isn’t command line only either for example that notepad popup for the commit messages. So they obviously think the same way.
“TFS work items or TFS build servers with Subversion, or Git, or Mercurial.”
You can work with work items regardless of source control system & MSBuild doesn’t care about the source control system, just look at the number of build runners that support it.
There is obviously some major advantages to using them with TFS Source Control, because it is integrated but you aren’t forced.
Disclaimer:
– I’m a ALM MVP: So some bias to TFS is expected.
– I use TFS daily and enjoy it and have felt some of the pain you mentioned, but not all of them.
– I also use Mercurial daily for some of my own work because TFS isn’t the right tool for those solutions.
– I don’t use GIT because of it’s shitty Windows support. So my knowledge of it may be lacking with GIT.
– Nothing posted is on behalf of Microsoft or my employeer, it is all just my personal view.
James,
As an ALM specialist [and the owner of a software consulting firm for over 25 years], I find issues with a number of your points.Over the past 5 years a significant of my work has been helping teams effectively use TFS. In a few cases migrating BACK to it, after ALM efforts have failed using other tools [I do also work with many other tools and environments including Linux and embedded systems – which do not use any Microsoft technologies/products]
Lets begin by the one place we agree: Working Software is the Goal. To achieve this requires a much larger audience than the “developers”. It includes everyone from the people involved in requirements gathering thru testing and deployment, as well as all of the activities that occur from the time the product is released until it is retired. Effective ALM must take into account all of the activities performed by all of these people.
When this scope is considered, the idea that Source Code Management is only a small part of the overall effort. Now lets tighten our focus to the developers (typically about 30%-50% of the people involved).
When a developer is writing code, they should be working on a specific User Story / Requirement or remediating a specific Bug/Defect. In order to do this effectively they should be able to query/view/update all of the artifacts that are related to the work in progress. They should also be able ot see all of the test results [unit, functional, integration, manual, user acceptance, etc. as appropriate for the stage in the lifecycle]. If this information is not directly accessible from within their IDE, then it is much more unlikely that the person will continually reference and update the items.
All of this is done without any direct interaction with “Souce Control”. The only real interactions with source control come at three points. Retireving a local copy of the code to work on [which requires access to the server regardless of which tool is used, since the current code resides on the server], Checking in the work as a task is completed [again requiring access to the server], and Creating Branches (which may be feature or release based).
For the teams I have worked with over the past 5 years, the average amount of time a developer spends interacting with Source Control is typically less than 30 minutes per day. The time a developer spends working with some other ALM related artifact can be between 1-2 hours per day. When you add in all of the population that interacts with the ALM system outside the developers, it quickly becomes apparent that focusing solely on Source Control Management is very unlikely to lead to a world class ALM environment.
@Robert:
Interesting point you’ve made there — “You can work with work items regardless of source control system & MSBuild doesn’t care about the source control system, just look at the number of build runners that support it.” I’d be interested to know how to use TFS build definitions for continuous integration with a Mercurial repository for source control. Is this doable? If so, are there any instructions (blog entries etc) you can point me towards?
@Robert:
Just a couple of other points. First, gated check-ins. These aren’t appropriate for a DVCS style of working — the idea behind DVCS is that your local copy of the repository is a private sandbox. You’d only run pre-commit checks when you push a whole series of commits to the central repository. Incidentally most DVCS teams do have a central repository. It isn’t particularly complicated either: DVCS uses repository clones the same way as TFS uses branches, so you’d have one for CI, one for QA and one for production and push from one to the next as the releases are signed off by the respective parties.
A lot of my whinges are admittedly minor nitpicks, but I’ve found a *lot* of them in TFS (I’ve only given a random sample) and they do add up to quite a bit of friction. But there are two in particular that I consider deal breakers: baseless merges and read-only files. I’ve really struggled to understand the rationale for baseless merges, and I can’t get a convincing answer out of the TFS ALM Rangers why they are that way either (in fact, they seem pretty defensive about the matter). Read-only files with explicit check-outs are also another fairly major failing, since they ring-fence development into Visual Studio and there are times when you want (read: need) to use something other than Visual Studio to edit your code. Unfortunately, TFS is not the only SCM that makes this mistake: so too do Perforce and Plastic SCM.
@David:
I would beg to differ on your point about integration. I find that when I’m working in Visual Studio, I tend to end up with up to about 30 different .cs class files open at a time, and TFS work items/source history tend to get buried in among them, then are all too easily closed inadvertently when you choose “Close all but this” on the one tab you’re working on. Personally I find it easier to have these things open in my web browser or Microsoft Word, since it’s much more ergonomic to type Alt-tab to another application than to Ctrl-tab from one class to another.
@James,
With regards to MSBuild being able to use other source control systems: this is easily possible.
We’re migrating from TFS to GIT but keeping TFS for work items and builds. We simply override the ‘get sources’ part in Msbuild to retrieve our sources from a Git repository. We wrote some custom MSBuild tasks that are simple wrappers around msysgit.
Works fine for us (still planning to release those wrappers as open source one day).
That sounds worth a try. I’ll have to have a play and see what I can come up with.
@David,
I’d just like to pick up on another point about your less than 30 minutes a day spent in source control. What exactly are you counting when you come up with that estimate? I’d guess that you’re only referring to time spent in the actual check-in window and waiting for Visual Studio to contact the server, and where appropriate, time in the conflict resolution dialogs.
Does it include the time spent on complex, error-prone, high-maintenance workarounds and hacks with configuration settings and if statements to get round the fact that your branching and merging support is not up to the job?
Does it include the time that your developers spend waiting for the build thanks to gated check-ins with over-strict policies, and then trying to track down the obscure problem that caused the build to break in the first place, during which time they couldn’t get anything else done in parallel because TFS doesn’t support ad-hoc, lightweight branching?
Does it include the time that your developers spend reimplementing an entire two days’ work from scratch because they’ve gone that long since they last checked in before realising that half of the approach they’ve adopted is totally screwy, and they only have large, bloated check-ins to refer back to that can’t be cherry-picked effectively?
Most seriously of all, does it include the time that your developers spend racking their brains trying to remember where they were at because the server has taken too long to respond, or presented them with a string of irrelevant files in the check in window that they haven’t even changed, or reported a whole lot of phantom merge conflicts in files that are identical, and it’s knocked them out of the zone and they’ve completely lost track of what they were doing?
Also, how frequently do your developers check in code? Most TFS users that I know only check in code once or twice a day on average, usually leaving only cursory commit summaries (if indeed they leave a commit summary at all) and seldom separating out the commits into logical units of work, and that being the case, 30 minutes a day is a lot of time to be spending on fairly slap-dash check-ins.
The point I’m making here is that there are hidden costs to inefficient or badly implemented source control that can have a massive effect on productivity. Good tools not only do their job properly but also keep well out of the way when they are not needed. Once you factor these hidden costs in, the case for end-to-end integration and relatively minor advantages for users other than developers becomes a lot less compelling.
With respect to the bigger picture of ALM, there are excellent tools like Redmine and Trac which address the defect and issue tracking aspect that seems to be brought up with regards to TFS.
Redmine and Trac integrate easily with a variety of VCSs and gives teams roughly the same functionality (albeit perhaps with somewhat less integration with Visual Studio). Both also happen to be FOSS.
If “working software” is the goal, there are likely better tools than one built on SharePoint to get it done.
People should learn to think for themselves rather than quote Martin Fowler for every single dev debate.
Er, excuse me?
Have you read this?
Nice article.
For me, ALM is a bullshit term used to sell bullshit software.
Some of the comments by ALM advocates on this article are laughably ignorant. Sorry, but there we are.
Precisely. The one thing I wanted people to take out of this blog entry was a plea for the ALM end-to-end-integration fanboys to get real. Some of the things they say simply beggar belief. All-in-one integration and cargo cult traceability do not excuse unreliability or a poor user experience.
I find the suggestion that the alternatives are only suitable for hobbyists and cowboy coders particularly offensive. Don’t they realise that by being built specifically for the Linux kernel, Git has proven itself from the word go on enterprise-quality, fault-tolerant, mission-critical software that sits at the very heart of systems where people die if things go wrong?
Another particularly offensive comment is the suggestion that we don’t care about team members other than developers because source control is only important for developers. If you are telling me that developers need to make compromises in one area to benefit other team members in what should be a completely unrelated area, you are, in effect, saying, “developers are not important.”
Jumping in to the party late
More TFS hate from another TWer ( http://derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html )
@Dean “Why would your TFS server go down? It’s a Microsoft product and therefore, it’s more easily handled by your infrastructure guys who like to support Microsoft products rather than open source apps. These days, there is no reason at all why TFS would be less reliable in terms of availability than any other product.”
As a former ThoughtWorks consultant I’ve been to five different companies using TFS. ALL of them have had significant TFS downtime. I can’t tell you whether TFS is more likely to go down than Git or not but I can tell you when TFS goes down you are screwed. If Git(or Mercurial) go down it’s a minor blip. Working offline with TFS is horrid, particularly when you’re unexpectedly working offline.
@James Even with Git I’ve found feature branching to be a bad experience. Branching and merging for very short periods of time is great and nearly pain free. Branching and merging over longer periods cripples your ability to transform a code base.
I’ve heard plenty of folks talk about the reporting in TFS as ALM. I’ve never seen anyone make meaningful use of it.
I’ve heard plenty of folks say that Team Build can do all kinds of great stuff. I’ve never seen a team do anything beyond compile and possibly run unit tests
Per standard MS operating procedure TFS is awful but the next version WILL ALWAYS FIX IT ALL…
Thanks for helping to expose the beast.
Steve
On feature branches: provided your tooling has decent support for them, (a) I’m a strong proponent of short-lived feature branches (less than a week or two), and (b) longer-lived feature branches can work fairly well if your team has the maturity and experience necessary to handle them. My recommendation for feature branches is to start off small and gradually increase the size of them as you discover what does and doesn’t work and you learn how to plan your tasks to minimise the risks of conflicts. This is the default with DVCS but completely the opposite approach to centralised tools, which say that branching should only be used for exceptional tasks. I’ve discussed all that in detail elsewhere — here and here.