I've spent a week trying to get TFS 2008 installed on my home infrastructure. It was the most painful piece of software that I've ever installed. And it looks like I was not the only one who felt that:
"Installing TFS has been a pain point for years. Although it’s gotten better, 2010 represents a quantum leap. The TFS installer now has 3 wizards: Basic, Standard and Advanced. The big innovation is the new “Basic” install wizard. It is a Next, Next, Next install experience that allows you to install and configure TFS in about 20 minutes or less (assuming .NET and SQL Express are already on your computer – a little longer if TFS has to install them for you). Both will already be there if you’ve installed VS 2010. The Basic wizard will install and configure IIS (if it’s not already there), install and configure SQL Express (if it’s not already there), and install and configure TFS. The only thing that really pains me is installing .NET 4.0 requires a reboot :(."
http://blogs.msdn.com/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx
Subscribe to:
Post Comments (Atom)
2 comments:
yeah!!! Good job Microsoft :-)
It has always been baffling as to why TFS was so difficult to set up. Perforce has never been that difficult to set up even when setting up a remote caching server for an outsourced team. It's good that TFS 2010 finally addresses that issue, though I have no intention of using it (Perforce and the various tools we've built around Perforce, such as the Hudson build system and our Hudson-integrated automated testing framework, are serving quite well in a cross-platform environment where various engineers are using MacOS, Windows, and various flavors of Linux to do their development).
I continue to feel that engineers pay far too little attention to packaging and deployment during the design phase of their projects. After all, project managers rarely adequately specify these to engineers because in many cases they've never been involved in the systems administration side of things and thus have no clear understanding of how enterprise-class networks and systems work, and engineers often feel their job is done once a working product is delivered to QA thus don't need to worry about deployment. Plus there is the engineering fascination with exposing inscrutable functionality that is absolutely useless to 99.999% of potential customers to the world, a fascination which is fed by product managers who want one more checkbox to put on the competitive analysis comparisons spreadsheet that goes to marketing. It's ridiculous, you end up with software that takes four screens full of data to do what one input box and one button should be doing, but that's what happens when you have geeks gone wild not thinking about how the product will actually be deployed and used by actual real human beings.
Unfortunately I don't know what the final solution is. I push back whenever possible towards a simpler, cleaner solution that does what 99.999% of the people need, not what that one person out of 100,000 needs (but which will confuse the other 99,999 people and cause yet more code bloat) , but it's like trying to push a landslide back uphill by hand, the only time I've managed it completely is when I've had full lead architect status and a product manager who was not competent to second-guess me. I'm glad that somebody at Microsoft has at last realized that there needs to be a basic, simple way to do things. I just wish that more of the industry (and indeed additional teams at Microsoft) had that same revelation, far too many products are uselessly difficult and tedious to install and use when there's simply no good reason for it to be that way other than the fact that marketing people want their check boxes and engineers are geeks.
Post a Comment