The irony is painful:

Thank God, the Pledge of Allegiance is unconstitutional. [more boom in the room]

Maybe I should subscribe to Brad Wilson's comments RSS feed.  A thread sprung up on his post on Advanced .NET Project Management post.  Sam offered that Brad shouldn't exclude IDEs for project management, Brad opined that IDEs are for amatuers, Sam threatened to open up a can of old fashioned whup-ass, and in the thread ended with generally amicable chest pounding.  Sam and Brad, I'll by tickets to that grudge match! :-)

I made a comment earlier about not using devenv.exe in the auto build.  I have some hard personal experience with this: at my work, we've been doing this since August.  I received a set of batch files from someone at Microsoft Consulting as a bootstrap to getting a build system up and running.  Things were pretty straightforward, except that on this project they weren't doing Web Services.  Things get complicated with building web applications. 

• You can root a virtual directory anywhere in IIS, but devenv won't understand this.  For instance, if you've got solution X and Web Service Y under X, if you get X at d:sourceX, it would be nice if Y ended up in d:sourceX\Y, not C:inetpubwwwrootY. 
• If there's a problem with the default virtual directory (if devenv doesn't like the one that's set up or whatever), the command line fails silently.
• Since devenv insists on building via IIS, to delete any previous copy of your web app, you may have to cycle IIS.  In our case, IIS was hanging onto that directory and I couldn't delete it without stopping IIS.
• The url to the web project is baked into the .sln file.  Greg caused me some headaches early on because he built the original solution and was running IIS on port 8080.  Nothing a little perl can't fix, but...
• For some reason, I had to build a .csproj.webinfo file in the web application's directory.  I didn't comment this and can't remember why I did it, but I do remember that the build wouldn't work without it.

The upshot of all this is that building web apps in devenv.exe is pretty tricky.  But the thing is, it's totally unnecessary.  All you need to do is invoke csc.exe (or whatever compiler you're using) on the source files.  I built some Nant build scripts and proved that all this was possible, and much simpler.  The one reason I haven't simply switched to NAnt is that we're using setup projects in each project to package our deployments.  I haven't found a way to do this in NAnt.  I suppose I could create a separate solution that incorporated all the setup projects into one solution, and then just build that out of devenv, but OTOH, I'm now rethinking the use of those MSI deployment packages.  Nifty as they are, it seems like they're not worth the headaches; mostly, you just need to copy the files where they need to go and then run installutil.exe to run any custom installers that the project contains.  Since our stuff is all being deployed on a server, most of what the MSI can do for us isn't really helpful.

As far as using the IDE during ordinary development, I'd be willing to bet that we'd have a mutiny if we took the IDE away.  Personally, I like working out of the IDE, definitely over textpad.  The difficulty would be in keeping the .build files in sync with the .sln files.  A nice little macro or addin that automatically exported a build file would be nice (VC 6 had the option to save a makefile with each save, which I've used in the past with good results).  Slingshot is OK, except that I don't like the format of the buildfiles it creates. 

Anyway, since our future development direction is WebSphere Application Developer, this question is mostly moot.  The thing is, I think I'll be taking the "IDEs are for weenies" tack when I start doing Java development.  It's funny that as terrible as WSAD is (everyone on our team acknowleges this), pretty much nobody is willing to abandon the IDE in favor of Textpad and Ant. 

A classic email called The Color Of Our Bike Shed - oringinally from the free-bsd list and now reposted on the IDEA community Wiki. It explains a lot about management, and managing Open Source communities. [rebelutionary]

Mike quotes a different section, but the part that made my eyes light up was this:

Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.

How true.  I've seen and been a part of things where simple proposals die because of the amount of piling on that happens, but massive, complex projects that cost up into 9 fugures get approved off of a 1 page summary.  The article also has some good, if sarcastic, advice for people posting on high traffic mailing lists.  I've signed off of most of the ones I was subscribed to because I simply don't have the time anymore.