I got an email today regarding a blog post by Jeffrey Palermo on the shortcomings of SharePoint as a development platform.

Now I have to say, SharePoint is not without fault (particularly in the area of feature packaging and deployment), but Jeffrey's perceived issues with SharePoint really show either the lack of personal development experience with SharePoint or a lack of creativity on the part of the team he's working with.

Let's get one thing clear first, okay?  SharePoint is meant as an enterprise collaboration and document storage platform, first and foremost.  One must always bear this in mind with regards to any discussion on SharePoint.  Why is it so big?  Why is it clunky in some places?  Why does it have to be installed on a server OS (okay, I admit, this one is probably more about licensing and $$ than anything technical)?

It seems that Jeffrey's major beef, that it must be installed on a server OS, kills any benefits of SharePoint as a development platform immediately.  So let's tackle this one first. 

First, a disclaimer: I'm not a SharePoint guru.  I don't have 5 years of experience with SharePoint.  I'm only going on what I've learned in working with SharePoint, day in and day out, for the last year.

In our development group of 5 or so people, we've managed to develop against SharePoint quite well, despite the fact that we all run XP as our primary development environment.  How?  Virtual machines.  Of course, some would view this as a hassle, as another stumbling block or quite clumsy.  I view it otherwise as there are numerous benefits in developing against a VM server environment:

1. Every deployment is exactly the same.  This means that server names, file structures, databases, and so on are exactly the same for every developer.  This aids -- not hinders -- the development of automated scripts and deployment utilities.  On our team, we usually synchronize images once every month or so.  What this means is that we'll take turns updating a common image and then everyone will grab a copy of said image.
2. Virtual Machines are easy to deploy.  It's called: copy-paste!  Nothing easier when adding a new developer to your team.  Instead of configuring a whole new SharePoint environment, just have the developer copy the latest development image.  So easy, a caveman could do it.
3. Virtual Machines can be rolled back.  Try doing that with your development environment!  If every developer had SharePoint deployed on his or her machine, a mistake (deleting/altering some core database tables or records, for example) would be devastating...it would mean at least a day of lost work time trying to rebuild the development environment.  Using virtual machines to host the server environment protects it from inadvertant dismantling.  And even if it is somehow altered for the worse, no matter, get another copy from someone else!  And of course, being able to rollback the image (provided that you created a snapshot) makes updates (for example, adding a SQL Server service pack) painless.
4. Virtual Machines are portable.  Why does this matter?  Demos!  There's nothing more convenient than having a sales guy pack up a copy of the VM with all of the software installed and tweaked for demos.  This is a huge bonus.

Look, the suggestion of developing with SharePoint in a "native" environment in a team is just plain stupid; it's a matter of working harder, not smarter and it shows a lack of creativity in terms of development management.  (One disclaimer: some Visual Studio tools from Microsoft for SharePoint cannot be installed on XP...this is a shortcoming, for sure, but it hasn't really affected our development.  If absolutely necessary, you can install a stripped down copy of Visual Studio on the VM).

Now let's address each of the other 7 points that Jeffrey brings up:

1. SharePoint isn't easy to install.  I'm going to skip that one because clearly, this man has never installed SharePoint.  It's nothing more than point and click...my gosh, I don't understand how it could possibly be easier.  Aside from this, using a VM approach, it only has to be installed once.
2. SharePoint isn't easy to configure.  See above.
3. SharePoint does not integrate well with simple tools.  I'm not sure what he means here.  Many administrative tasks can be handled by stsadm.exe which in turn, means that many of the administrative tasks can be handled by batch scripts.  Aside from this, SharePoint is just an average ASP.NET application.  Stopping and starting IIS, xcopy, and so on...these are all still applicable to a SharePoint deployment.
4. SharePoint isn't easily extended to make simple tools.  What?  Nothing could be further from the truth.  The only beef that I would hold is that Microsoft doesn't package the SharePoint DLLs separately so you have to extract the DLLs from the GAC of your server environment.  But once you do that, it's easy to reference and use the API by copying the DLLs to your development environment.
5. SharePoint isn't easy to debug.  Again, I'm not sure what the issue here is.  The process of debugging SharePoint applications (web parts, layout pages, etc.) is no harder than debugging any standard, run of the mill ASP.NET web applications.  Okay, sure, you can't just hit F5 (oooh, the horror!), but seriously, I hate F5 developers - sometimes, F5 just isn't the way to go, dude.  I'm also pretty sure chimps (or macros) can be trained to hook up the debugger and hit F10 and F11.  As for debugging core SharePoint, well, I guess he has a point since the source and debugging files aren't available (not that I know of), but I don't see that as an issue.  I mean, how many platforms ship with debugging symbols included?
6. It's not easy to create test automation for SharePoint.  There is some truth to this since it requires the developer to learn about the platform first (API, database tables, web services, and so on).  But I don't think it's any more difficult or challenging than setting up automated tests against any other third party platform.
7. SharePoint configuration does not store easily in source control.  See above regarding VMs.  Aside from this, he's got it all wrong again.  We can look at this from a few different angles.  First, SharePoint is just an ASP.NET application.  Repeat that to yourself about 100 times.  With regards to application configuration (in terms of the web.config), it's as simple as copying the web.config to your source control system and using a script to deploy it on build.  Secondly, if we look at the configuration in terms of web parts and layout pages, it's possible to include these in source control as well using solution packages deployed either on build or manually as features.  Certainly requires a bit of research to get it working the first time, but it's not a task that takes more than 1-2 days of experimentation.

From personal experience, I've found SharePoint a very compelling application development platform (again, that's not to say that it doesn't have shortcomings) because it's nothing more than ASP.NET but with the added bonus of a document management/storage API, profiling, permissions, and it acts as an integration platform for a variety of applications. 

You can make it as hard or as easy as you want it to be with regards to developing applications for SharePoint.  It's only a matter of how much time you are willing to put into flipping through the API and understanding the fundamentals of working with SharePoint.  A big part of successfully and painlessly developing against SharePoint is creativity in terms of setting up your development environment and automation (batch scripts, pre/post-build scripts).

The points that Jeffrey, didn't bring up -- the true pain points -- are really "fringe" features so far as I'm concerned.  Namely, this centers around SharePoint hosted and integrated workflows and InfoPath (because no one likes and no one actually uses the otherwise useless and purposeless InfoPath).  You're not required to use InfoPath or SharePoint hosted workflow; in FirstPoint, absent the early documentation and tools required to be productive on this front, we made an early decision to host workflow in our own environment. Sure, we miss out on some of the native features of SharePoint like workflow state visibility and integrated forms via Forms Services, but I don't see it as something we can't overcome as documentation and tool support becomes better on this front.