The true cost of TFS, is it really "free"?

You say you've got MSDN premium, so TFS is free, good for you, it is developed and supported by Microsoft, should be a great product then??

Anyway in my personal opinion, it sucks, but try telling that to none technical people, its actually really hard, and they still insist you use it because its designed for enterprise use, isn't it?

So i thought id do a 'back of the napkin' calculation of how much it actually costs.

Our dev team is apparently worth ~40k a month, consisting of 4 devs, designer, tester, db admin, tester, ba,
10 people, for arguments sake ~4 grand each per month.
So if you take a dev pair thats 8 grand a month, or 2 grand a week.

Where is the waste (source control)?
Check-ins :- We check in 7 to 10 times a day, each time it should be instant, but mostly TFS cant quite manage it, it needs user interaction to resolve the easiest of changes, some times it cant even manage to insert new lines. So estimate 3 minutes extra per check-in thats 20 minutes a day extra, or 2 hours per week. (Caveat, if you are working in the same area of code as another pair be prepared for this to at least double, ive had some awful merges in the past even when the conflicts weren't really that hard)

Get latest :- Sometimes get latest doesn't even get the latest, leaving files out or just getting it wrong?? how?? so now and then we need to sort it out, usually after wondering what on earth is going on and trying to debug your code only to find out my source is not up to date (10 - 20 mins per day on average, 1 hr per week)

Get specific :- So, often you start using get specific instead of get latest, this is slow so we try not to do it all the time, only when we think there might be a problem, the code base is big so this takes a lot longer than a get latest 2-3 minutes extra per check in, but only done 2-3 times a day (7 minutes per day, 30 mins per week)

Merge to main (feature branching) :-
Depending on how often you merge to main, and how many other teams you have also checking into main that is going to hit you quite hard. if you are a lone team with out any teams changing your code base you have it easy and can discount this step. for me its at least a 4 hour job of doing the merge to main once every month)

Where is the waste (Build management)?
MSBuild and TFS :- This is complex, significantly more complex than the same projects built with nant and cruse control, Team city, Go, et al. it sucks a lot of our time when we need to change the builds, its hard to say how much worse it is, our code base is quite old and complex, lots of build dependencies, this needs fixing, lets be conservative and say it only takes 1 hour extra per week to maintain TFS over any of the others.

Total Waste
2 hrs + 1hr + .5 hrs + 1hr = 5.5 hours of waste a week, lets call it 5 for now, I like round numbers.

So a pair of devs is on 2 grand a week, 35 hours = £60 per hour
5 hours waste = £60 * 5 = £300 per week per pair
2 pairs in our team = £600 per week * 4 = £2,400 per month on a £40,000 dev team

Thats just a 2 pair team, if you have even a moderate size team of 4 pairs you are going to get even more pain, with developers effecting each others check ins.

Oh and what about that merge to main hell we discussed (if you are feature branching), add 4 hrs * £60 per month = £240 extra.

Summary :-
your "free" version control and build agent is not looking so "free" any more.
Its costing us at least 25 grand a year... that sounds wrong? can you please check my math...

How much is it costing you?

Disclaimer:-
In my opinion I've been quite lenient in my estimates, but when you say the numbers and add it all up it sounds awful, but it is.
Also the numbers above don't take into account other teams costs, if you have 3 dev teams (like ours) all working on the same source code, merging every month (feature branch style), all having the same pain, the figures quickly become a big drain on the business.

Problems :-
The main problem I have is how to quantify the waste, often its small things here and there, they just add up, not all the time, but especially if the team is doing TDD properly and going through refactor cycles frequently, which we are.
Any ideas on how to quantify the waste better would be appreciated.


Amendments (11-03-2011)
Thanks to my reviewers (kat, skain) for pointing out my grammatical and spelling errors (now corrected). But i did just knock out this article in the gaps i had whilst waiting for TFS, i guess its good for something. Joking apart though this does lead me to something i didnt mention and that is context switching inefficiencies. So every now and then you get 5 minutes to do other tasks, email, ect, but this is a big context switch for the pair, it takes a little time to get back into the flow again, this cost is not accounted for in the above monetary costs.

20 things that are wrong with TFS, and counting

We have recently spent a lot of time using TFS 2008, im no expert with this tool but it seems to me that there are lots of issues with it. Its not that im trying to do some TFS bashing but my last project using subversion didn't have source control problems.

As always though if anyone out there can put me right on any of these issues please do so.

1. Renames and deletes don't always properly get merged between trunk and branch and back.
2. We had really random deletion of files when doing a merge from a branch that has had a baseless merge applied to it, (files were randomly deleted off the trunk during merge) these files existed in our branch and the trunk before the merge, but were removed off the trunk after.
3. After doing a baseless merge (using power tools on the cmd prompt) you then can't reliably use the TFS GUI to do things like merges, you must use the command line tools.
4. Tooling just doesn't work when merging, files that have no conflicts just don't auto merge all the time and requires manual intervention for no reason. This is intolerable when refactoring and you have changed 100+ files.
5. No ability to create patch files which can be subsequently applied to other branches.
6. Changes to one branch cant be merged into another branch unless you go via the trunk.
7. You cant merge workitems between branch and trunk, even though workitems are the main unit of work in TFS.
8. Many standard features like rollback are not built in. It requires an additional 'power tools' download (There is no GUI for rollback)
9. Can't seem to rollback to a given point in time, you can only rollback 1 changeset at a time, this just seems wrong to us?
10. Using TFS built in diff tool reports lines that have no changes to have changes. And does not line up source and target very well making the tool very hard to use when trying to spot important differences.
11. Doesn't know that files or folders have been added unless you tell TFS in the GUI, This can easily lead to files not getting checked in if they were not created in visual studio.
12. The GUI doesn't always update to reflect the state of the source control, requires a refresh, this mainly effects the pending changes view.
13. The UI is confusing in that if you are browsing the source and click on a file to open it, it opens the local copy not the one in source control. Also it doesn't tell you that the local is different from the one in source control.
14. When you add a new mapping to your workspace the tool says 'do you want to update your workspace?' when you say yes it then goes and gets everything from your workspace and updates everything, you expect it to only get the changes due to the new mapping. this caused us quite a lot of confusion and wasted time, but luckily nothing was lost.
15. Sometimes labels disappear, completely, as if they were never created.
    
16. A label to label comparison does not always give the same results as a date to date comparison, even though the dates used are the same as when the labels were created.
17. Checking out (not getting) the entire branch takes ages (40 minutes plus) even though the source is not really that big (70,500 files), we actually gave up in the end and 1/2 were checked out 1/2 were not.
18. Deleting a branch took 40 minutes. Did a delete in TFS of the branch folder (took 10 mins) got a pending delete dialogue box, tried to check in the delete which failed with the error 'the local copy is not up to date', so we then undid the delete which took 20 mins, got the latest source (3 mins) and finally did the delete again (10 mins). Why cant TFS tell us up front the delete wont work because our file system is not up to date? and why when doing it in the TFS GUI does our local file system matter? especially since we had no pending changes?
19. When you re-branch you lose your branch history.
20. If you tolerate this, then your code will be next...