In his recent post on Configuring the Stack, Jeff Atwood discusses the frustration that comes with installing a complete development environment. 

I'm having a hard time seeing how Microsoft's commercial stack is any easier to configure than the alternative open source stacks these days. Either the open source stuff has gotten a lot more streamlined and mature, or the Microsoft stuff is somehow devolving into complexity. I'm not sure which it is, exactly, but the argument that choosing a commercial development stack saves you time rings more and more hollow over time.

You can read through the comments and see that many people have jumped at the opportunity to bash Microsoft and espouse the virtues of the competing open source offerings.  What I think that Jeff and some of his readers are missing is that his list of tools is an entire stack and once installed is in a useable state requiring almost no additional configuration in order to begin development.  To equal what Jeff has installed you would need:  A compiler (for 4 languages - I'll be generous and let you pick any four compilers for your favorite languages), a code editor, a web server, a database, unit test framework, load testing framework, functional web test framework, a web framework (like Struts or RoR), a version control client, a bug tracker client (if you use a web-based bug tracker then your browser counts), a db comparison/diff tool, a db query tool, a report writer and a UML diagramming tool.  I know that there is a lot more features that I am glossing over, but to think that Emacs represents an entire "stack" or that GCC is somehow equivalent to VS.Net (any edition), as suggested by some of the comments, is pure fantasy.

I lived in the Java OS world for several years and it is no different.  You install Eclipse, Java SE, J2EE, JBOSS, Spring, Struts, a db of Choice, junit, an svn client and whatever you are using for bug tracking.  This is just the installation.  Then you have to actually go through and manually edit several different configuration files.  At that point I would consider that you have a large part of what Jeff has installed.  You might still need to install a diagramming tool, a reporting tool, a few more db tools and some additional testing tools.  Where I think that Microsoft excels is that getting all of those tools to work together is relatively simple.  The same is not true in other environments.  While the Java world is getting better with the rise of Eclipse and the domination of JBOSS, you still often end up with a patchwork of tools and frameworks that are needed for developing the advanced systems that are currently de rigueur in the desktop and web worlds.  If you look at other environments like Python, PHP, or Ruby you still have all of those same issues, except that many of the tools are not nearly as mature as Eclipse or Visual Studio.

Don't believe the hype, OS is no panacea.  We live in a complex computing world and build very complex applications.  We should expect that our development environments would reflect this reality. 

My bigger beef in this whole situation is that Windows has always had a stability problem such that every 12 to 18 months you are forced to re-pave your system just to get back to a re-useable state of existence.  If I could keep my Windows installation from rotting over time then I would gladly pay the installation price one time and be done with it.  However, it becomes hard to swallow having to set aside a couple of days every year or two just to refresh my whole system due to the crud that builds up in Windows over time.

Dare Obasanjo posted about Three Things I Learned About Software in College, which Scott Hanselman followed up with Three Things I Learned About Software WHILE NOT in College.  So here are my lists:

Things I learned about software in college

1. Never close your eyes to learning.  The world of software is constantly evolving and if you don't stay in a learning mode, you will fall behind.  I started college writing code on mainframes and left college coding on PCs.
2. There is no one perfect language.  There are the languages you know, the languages you don't know, and the languages that have yet to be created.  If you are following rule number 1, then the language you use today is likely not going to be the same as the one you use 5 years from now.  Get used to it.
3. Programming is primarily about problem solving.  Improve your logical thinking skills and you will improve your programming skills.

Things I learned about software WHILE NOT in college

1. No matter how good of a programmer you think you are, there is always someone better and faster:  Unless your name is Scott Hanselman.
2. You are not as good a programmer as you think you are.
3. Often, "good enough" is "perfect".

Things I THOUGHT I learned about software in college (but which I apparently need to keep re-learning)

1. Some of my most brilliant code was written in the wee hours of the morning, the night before it was due.
2. Some of my buggiest code was written in the wee hours of the morning, the night before it was due.
3. Good code rarely happens in a vacuum.