I dread installing application servers. I mean I really dread them. Rarely have I installed one that went off without a hitch. The first time. Usually, something goes wrong, I get a cryptic error code, hit Google looking through posts on unfamiliar websites looking for help, and watching the hours pass by.
Not my idea of a good time.An example of a really nice install is the one that comes with Microsoft SQL Server. Those guys got it right out of the box. You run the install, verify a few simple things, which are defaulted to appropriate values, and away you go. I don't recall ever having a SQL install go bad - the closest thing was an install getting confused due to an existing installation of SQLExpress and not installing the tools I needed by default. That was a bit of Google surfing until I found the answer, but all-in-all a nice install for an admitedly very complex (maybe the most complex product) by Microsoft.
Then there's Team Foundation Server.
First, TFS is an awesome product. Once you get it installed. And that is an accomplishment by itself. I've been using TFS since it first came out and its not only far better than Visual SourceSafe for enterprise-grade version control, it also allowed us to stop using SharePoint as a place to store project-level information such as requirements. As we moved to a more Agile stance using Scrum, the ability to integrate project templates that allowed us to work the way we want to work was incredible. Although the new feature set for TFS 2008 isn't massive compared to TFS 2005, it's a nice release with some much needed features like a supported Web interface to the application server.
But then there's that install part.
TFS is an application server that needs a lot of other application servers in order to do its thing - SQL Server, SharePoint Services, Internet Information Server, SQL Reporting Services. Now, each of these servers have to be installed (or not) and configured just a particular way for TFS to install properly. You get it wrong, you're, at best, un-installing/re-installing software, or at worst, zapping the hard drive and starting over with a fresh Windows install.
In TFS 2005, there was a lengthy install guide that went through pages of specific steps to install TFS and its needed application servers. In TFS 2008, the document is updated, but it's still a lengthy process. I was amazed that there's still a large amount of secondary tasks that have to be done either with command line invocations using XML scripts, downloading and running PowerToys tools from Microsoft to address missing features, and so on.
So you begin with reading the guide, and starting with a fresh Windows 2003 installation. Hopefully fresh. Then, you proceed to install IIS. Be careful to install the ASP.NET pieces and the SMTP server if you want to send email (you will, believe me) from TFS. Of course, it's easy to miss these options and not be sure you want to deal with, say, SMTP until later. At no point does the guide say "Here's what you need to do at a minimum" and separate that from the optional stuff.
A more nightmareish example is SharePoint Services. Woe unto the rash developer who blindly thinks he or she can just run the TFS install, or SPS install and away you go.
You forget to install SPS assuming a server farm? Oops, start over.
You configure SPS yourself after installing it? Oops, start over.
The documentation also says that you can install SPS yourself (preferred) or let TFS do it with no clear indication why you are asked this - I mean isn't this what an install is supposed to do? If you install it yourself, you are reminded to install an update to SPS after TFS is installed, or you can let TFS install SPS with the update for you. Confused? You're not the only one.
And don't get me started on the integration between SPS, TFS and SQL Reporting Services. Even after the install works and everything is done, you then find out that no one has access even though you added users to the proper TFS groups. Why? Because SPS and/or SQL Reporting Services don't know about the user. Synchronization problems? Likely. So you download yet another tool from the helpful Microsoft Support team that allows you to twiddle with the rights of users (or add new ones). You probably would have thought that there's be an Admin console in TFS that would coordinate all of this.
Nope. There's none to be found.
Finally, woe unto the unsuspecting admin who starting messing with SPS itself in this TFS arrangement. You can very easily hose the SPS environment so that voila! TFS can no longer find your SPS applications, you can't create new ones, and so on. Solution? Hit Google, look through a lot of unfamiliar web sites looking for help, watch the hours go by, ... Sound like a pattern?
But please understand, I love Microsoft software. I really do. But to see such a fantastic product as TFS get such a poorly designed user installation experience is a tragedy. It doesn't matter if TFS scales, has features coming out of its proverbial ears, has the latest technology, etc if you can't install it. And many likely customers would give up and go with an Open Source solution like Subversion.
In the Open Source world, it's assumed that all software is written by disparate groups. There's no controlling entity deciding how everything should fit together. Yet very often, especially at the application server level, things fit together quite well. In the Microsoft world, we agree to dominance by a single vendor in exchange for a wonderful user experience. And user's include the installers.
We're people too.