Caught That Old Time Religion

What an appropriate title coming from an Architect Evangelist J

I have come to learn from my short time at Microsoft that I am somewhat of a late adopter. It took me awhile to be convinced that BizTalk was not as horrible as it was in 2000 when I got to suffer through work with it as an early adopter. I was decidedly late on the AJAX bandwagon, and I still am not completely sold on the notion of moving back to thin client computing. I get why Facebook and MySpace are fun to use, I don't get the fervor around Web 2.0 and trying to label any use of AJAX as the next big thing. I have been using XMLHTTPRequest for years, and have programmed the client DOM long enough to have a strong distaste for everything JavaScript.

For the past several years, I have heard people talk about SharePoint as the Microsoft application platform. I have been quick to retort, "There's only 1 platform, it's Windows." That is, Windows provides all the base components that compose the overall platform. IIS provides application activation and isolation, ASP.NET provides a framework for web delivery, and .NET provides an abstraction over the base platform services (IO, memory management, threading, security, etc) that are exposed in Windows. There are solutions that sit on top of the platform, such as BizTalk and SQL Server, that enrich that experience. In the past, I lumped SharePoint into that view as well.

I have not completely abandoned that view, but I am starting to see my world view through different colored lenses.

.NET still provides a necessary abstraction over the base platform services. Let's face it, this is sorely needed, since nobody really likes programming in C++ or Assembly given their choice. And if you are one of the freakish few who hold onto the concept of low-level control versus productive abstractions, I only ask how that's working out for you and how that job market is faring these days… I don't see a whole lot of business betting their shareholder's money on rebuilding widgets that are provided through a drag-and-drop experience. And there's where my own definition came to odds with itself… I see many more companies opting for leveraging SharePoint for its out of box experience than I see ASP.NET developers creating from scratch.

You see, for years I have said that higher-level abstractions provide increased value through productivity. It doesn't make any sense at all to pay a developer to build something in 1 month that you could have bought for the equivalent of 1 week of their salary. Not Invented Here syndrome coupled with Fear of Licensing makes a pretty powerful molotov cocktail. Despite me being the one to really investigate build versus buy decision, I somehow still didn't make my own mental leap to see the build versus buy decision of implementing ASP.NET applications from scratch versus deploying SharePoint… which is basically an industrialized version of ASP.NET. In fact, many of the things that take up ASP.NET developers' time (customized membership and role management, page navigation, provisioning, deployment, scaling) are all taken care for you out of the box with SharePoint. Even more to the point, we spend a large amount of time writing database schemas and creating application pages that map to those schemas, and typically we do that at least twice per database entity (1 application page, 1 management page).

Enter SharePoint… it already has provisioning, roles, membership, common themes, page navigation, scaling… all the goodness of ASP.NET 2.0 at your fingertips with all the drudgery done for you up front. It already has a well known CSS structure that enables you to choose from a large pool of web designers who can leverage their past work on SharePoint's CSS to deliver new experiences. You can use most or all of the ASP.NET 2.0 library code that you have built up over the past several years. Feel like provisioning yet another database table? Resist and create a SharePoint list. Feel like creating a web form? You can, but look at InfoPath and see how much time you could have saved. Thinking of writing an ASP.NET app? Take a look at SharePoint and Windows Workflow to see if that doesn't meet your needs much better.

If I seem like a fanboy, I am. However, it took me longer than most to catch on to the secret.

Desptie my recent fanaticism, there are still some obvious warts in the developer experience for SharePoint. First, you need to become familiar with some base terms (features, lists, site pages, application pages, edit and control block, and CAML). If you start developing ASP.NET application from scratch, you get to design all of the bad decisions yourself, versus leveraging someone else's bad decisions in SharePoint. The truth is that, even with the ugliness that is CAML, there is a ton of goodness in SharePoint. And you can't ignore the fact that it provides a heck of a lot more than simply emitting a table that you can edit and sort data into, you can provide that capability time and time again by exposing a webpart.

One of the top technologies to learn today isn't LINQ or Entity Framework or WPF or WCF… It's SharePoint (either WSS 3.0 or MOSS 2007).

Paul Andrew recently blogged about a webcast series that focuses on introducing SharePoint for existing ASP.NET developers. There's some fantastic material in there, and I can state first-hand that this will significantly reduce your learning curve (this is the kind of material you typically pay thousands for to ease the learning curve).

Hope to see you there…