Ever been working along on something, and you see an ad or get an error that just boggles the mind? You look at it and just think to yourself, “what the… why did they… I… don’t… can’t… even… imagine. Ugh idiot!” Well here’s a few that have hit me lately.
I know, really, NOT a big deal at all. 1 penny. But seriously, it’s supposed to be the free tier. It probably cost MORE to charge 1 penny against my credit card than to just fix the mistake. Meh, whatever, it’s rather hilarious really.
I got nuthin’. Seriously, this is inexcusable for a corporate environment. How many other security protocols or other things are completely in disrepair? This type of nonsense actually concerns me. (and btw, this was using Chrome, the IE message for IE 9 came up the same way)
Oh dear. It’s bad enough using TFS internally, but hosted! I can only imagine the horror! In addition, at $20 bucks you could have gigs upon gigs of private storage for a Git or Mercurial account. My take, go get an Unfuddle or Repository Hosting Account and use a seriours distributed source control system. It’s time to step away from the sourcesafe… err, I mean TFS… and use a functional, scalable, and non-hindrance prone source control system.
Hope that was entertaining. That was my PSA (Public Service Announcement) of the week. Enjoy.
My experiences w/ TFS have been good. What’s your beef w/ that tool? Maybe I’m missing something.
Let me list the ways.
Poor synchronous architecture (i.e. locks up frequently on heavy use networks)
Not properly distributed (at any level)
Too Client Server Oriented. Most software designs have moved well past this years ago.
Source control is very buggy on the system. Even the internal build has build issues, but they’re ignored because it isn’t “high priority” enough.
Source control is not distributed and makes remote (i.e. disconnected) work very difficult, especially if not used EXACTLY like the TFS System expects you to.
The Build Management and setup takes excessive amounts of work.
It forces focus on the tool over people, very NON-agile in ideal. Not good for extremely fast paced, high quality, project and code teams.
Reports take excessive amount of time to setup, as does the setup in general. 2x or more steps than TeamCity + other options.
The web interface is very 1990s. It is 2011, we’re moving to Web 3.0 now, and the design & UX hasn’t even hit Web 2.0 yet. Very frustrating.
It doesn’t work well with graphic design, UX, UI, or other non-code professionals.
It forces Visual Studio usage to do almost anything.
It forces multiple state management methods around where files are (in source, out of source) and attempts to manage things it shouldn’t, allowing people to use source control that have no idea how to actually use source control. This doesn’t really help create stronger, more capable teams.
…I can go on, a lot, about all the nuances and refusals from Microsoft to fix known issues with TFS. 🙂
TeamCity + Git + JIRA is a vastly superior option. Better code, better architecture, better usability, faster builds, better quality code management, better source control… and that list could go on. I could outline other options too.
I guess the best comparison really and best advice I could profer is, use the TeamCity + Git option as a developer for a about a month, learn it well, and you’ll find dozens of reasons yourself why TFS is just not up to par. An analogy comes to mind, driving a model T of yesteryear and then drive a nice new high end Audi. The Model T does the same thing, gets you from point A to point B, just slower, less comfortably, with many less features, and not as safely.
Anyway, enough ranting. Maybe I should just write a “how to fix TFS” blog entry. 🙂
I don’t know why you go on and on and on and on about TFS, whether it be twitter or your blog.
If you think it is crap, why not let it die its own death and focus your energies on something you think is worth while?
I worked on a largish product development for 2 years from the start of 2008. We had about 15 devs, a few BAs, 5 testers, and 2 PMs. The project was run on TFS and it served us perfectly well. The integration with MS project was useful, our checkin -> build -> code review workflow was very efficient.
There were two things that actually impressed me :
1. Shelvesets. This is somewhat analogous to branching but very simple and useful. People were often experimenting with things and would email others “can you have a look at my shelveset x and tell me what you thing”.
2. Merging. The automated merging algorithms they have are superior to anything I have seen. I can only recall a handful of times where I had to do a manual merge. Often I couldn’t believe the merge worked automatically, but on inspection
In general it was very easy to use, nicely integrated, reliable, and no one even thought about it.
The reason no one thought or discussed it much was because there were far more interesting things to think about.
All the reasons I listed above.
It took a total of about 30 seconds to write the response… if it saves a single developer the hours of torture, if it gives just one project a refocused approach to assuring that TFS doesn’t become a road block, that 30 seconds was worth it.
I’ll admit, Shelvesets are pretty cool. But not something unique, only the naming of the feature is.
Merging? You’ve got to be kidding me… anyway. That sounds more like the team you were working with was very disciplined about your check-ins, TFS has notoriously horrible (or completely lacking) merge capabilities of any caliber without 3rd party additions. Personally, I prefer team discipline and not stepping on each others toes, but I’ve never seen – even at Microsoft itself – the merging work well.
But I digress, I agree with another point, this isn’t the more interesting part of software development in my opinion either. Some people might find source control very interesting – but I prefer other bits. Stay tuned and you’ll see those really soon. I have an AppHarbor Deployment video coming up soon too. Interested in cloud tech?
I guess you hit the nail on the head. You probably need very sophisticated scm software if you are working with a team of scatter brains who cowboy changes all over the place for weeks before checking anything in, and want to have a local repository so they can flip/flop back and forward as they try things they don’t know will work or not and are too embarrassed to commit to the main branch/trunk.
And you probably don’t need the best scm if you are working with sound engineers who plan their work, communicate with colleagues, and who commit small reliable and ‘completed’ changes to the product.
Yup, manifesto item #1.
“Individuals and interactions over processes and tools”… I can get on-board with that.