When you develop a regular ol' web site in Visual Studio, you just say "create a new web site". You create your pages and web controls, classes, whatever you find necessary. To debug it, you set your breakpoints anywhere you want and hit F5. Studio these days even launches its own built-in web server, so you don't have to set up IIS. You can even change your code on the fly in some cases. When it comes time to deploy, you grab the code, copy it to the server, point IIS to it, and you're done. (Ok, it's rarely that simple, but it can be. Throw in a few web.config changes or other optional steps like pre-compiling if you wish...) How easy is it to develop a SharePoint site? First, you have to install SharePoint. While I've never actually done this step, I can't really say that it's hard or easy; however, since IIS comes pre-installed, it's a pretty simple bet that installing anything is more difficult than not having to install anything. Considering how big SharePoint seems once you get it installed, I imagine installing and configuring it can be extremely complicated. Or perhaps it's fairly easy if you just accept all the defaults. I'm working on a SharePoint project that, so far, we've tried building an event listener, a web part, and code that uses the web services. The event listener works fine, except that to debug, you have to: manually create the list in the SharePoint site on every developer's instance of SharePoint register the listener class library in the GAC use a command-line utility to register the listener with the event run IISRESET to restart SharePoint attach the Visual Studio debugger to the SharePoint process Fortunately, a batch file takes care of the middle steps, and the first step only has to be done once. Still, it's a lot of extra overhead, and it has to be done for every listener that gets created. The web part has been the responsibility of another developer. Based on his comments, I gather that designing a web part involves practically designing a whole web page. What I remember from them in a previous job, setting them up and deploying them was a royal pain. Modifying them was considered something you just Didn't Do. Their solution was that they had a web part that had, as a parameter, the path to a web control. If you wanted to create a new element on a web page, you created a regular .ascx web control, dropped the "container" web part on the page, and set the path property to the location of the .ascx control. Probably the only easy thing about that job. The web services are supposed to be easy to use. They have been decidedly not so. My tasks have revolved around trying to interface with the default document library. I can access documents by using the URL http://localhost:ip/Docs/Documents/filename.doc just fine. And yet, if I try to get any information about the document library itself, it tells me the very document library from which it is serving documents doesn't exist. This is most evident when I use the Dws.GetDwsData method on an existing document. It returns a load of information (including a "LastUpdate" parameter which, instead of being a piece of useful information like when the document was last updated, is a key for future calls to see if it was last updated since a given key). One of these pieces of information is a reference to the Document library, which it returns as an error code, "ListNotFound". Because this document library that these documents are stored in doesn't exist, I can't use other methods I need, such as Versions.GetVersions, Dws.CreateFolder, or Lists.GetListItems. And we haven't even gotten to the point where we try and deploy SharePoint content yet. As I already alluded to before, there's no real way to transfer content pieces from one machine to another in any easy or automated way. A simple list had to be manually created on every developer's machine, and it'll have to be done on Development and Test. In that previous job, they had an established procedure: back up the entire SharePoint database from development, and restore it in the test environment, then QA and then Production in turn. (Which, yes, meant you can't store any development or test information in SharePoint.) While I was there, for the first time, a SharePoint List was used to store data instead of content, and they had to bring in a Microsoft consultant to write a special utility to export the data and re-import it, so it wouldn't get lost in the complete-backup-and-restore deployment procedure they had for years. Because, of course, no procedure currently exists. Supposedly, SharePoint is what companies want, because it means they can manage content without having to go through development to do it. Case in point, we have a static web site that we're moving into SharePoint for our client, because every change they want to make, they have to call us to make it. The problem is, it's taken our one consultant, the one who's supposed to be experienced in SharePoint, all week to get the existing site into SharePoint, and he still hasn't even gotten the framework in place, let alone the content — something even he agrees would take maybe two days, start to finish, to completely rebuild in a standard ASP.Net site. Where it seems to make sense to set up a single-environment easy-to-manage web site and collaboration area, it is a nightmare for multi-environment (i.e. Dev, Test, Production) migration and custom development. And yet, it's what the people at this consulting firm keep selling like it's the Holy Grail. I have my own theories as to why this is, but the fact remains, we're stuck with a tool that just refuses to do the job, and tasks that should take half a week are becoming impossible to do in two.