In a previous post I discussed some of the trials and tribulations I’ve encountered with the mandate that we replace our current document management system with SharePoint. From the comments on that post, it sounds like pretty much everyone hates SharePoint to some extent.
Now, users, tend to hate anything that requires that they follow procedure or document their work, so it’s not entirely SharePoint’s fault. But some of it might be that SharePoint is being used for things it shouldn’t be used for. It’s a tool, and just like any other tool, it’s only good for certain situations. And even more to the point, it seems to have certain economies of scale as far as productivity goes.
Small List Management Applications
SharePoint’s forte is lists. Out of the box, SharePoint goes above and beyond what the typical custom application can provide. You can build fairly structured lists, link them together in basic ways, export them to Excel, and perform basic sorting and filtering. Users can keep up-to-date with changes using Outlook integration, email alerts, and RSS feeds. For documents, it has check-in/check-out and versioning. If you really want to get fancy, all of this data can be accessed through web services.
It’s a good alternative to wikis and forums that offer low overhead but very little structure, as well as things like Excel that offer no centralization. If you had to write an application to provide this sort of list management functionality, it would take quite a bit more time than setting up a basic installation of Windows SharePoint Services. And odds are it wouldn’t have anywhere near the feature set that WSS offers.
The bottom line is, SharePoint’s going to save you a lot of time in these situations. But you’re relying on out-of-the-box functionality, so there are limits.
If users start asking for things that SharePoint can’t do out-of-the-box, you have two options: you can either extend SharePoint with .NET/ASP.NET, or you can kludge together customizable features like views to do more complex things.
If you find yourself tempted to do either of these things, take a step back and reconsider. At some point, it’s going to be easier to write a standard ASP.NET application than it is to extend SharePoint or teach users how to use those advanced features.
While SharePoint can be extended without learning a new programming language, you’re still going to have to pick up a new skill set to do it effectively. Installing and debugging SharePoint features is a daunting task. (This is something I may go into in a later post.) So expect to waste a bit of time trying to get “Hello World!” working right.
SharePoint also isn’t a structured, centralized data store in the same sense that, say, SQL Server is. You can’t query against it for reporting purposes in the same way you can a database1. If you users have access to create their own sites and lists, don’t expect anything as permanent as a table or as strong as a relationships. If you need any of these things, you’re probably better off with a database-driven application.
On a side note, though, if you do have to move away from SharePoint, the SharePoint object model makes getting data out of a site extremely easy to do with some basic C# programming.
Large Applications Leveraging SharePoint Features
While I’m being very negative about SharePoint development, it doesn’t appear to be a bad thing in the right situation. For the average .NET developer who’s only doing SharePoint as a one-off project, it’s a bad idea. The learning curve for SharePoint development seems to tip the balance between the essentials and incidentals of programming2 in the overwhelming favor of incidentals.
But, if you have a couple of programmers on your team that you can dedicate full-time to SharePoint, it may not be such a bad thing. The learning curve can drop significantly if the developer is able to focus on the books and training and then start playing around with it on a development server. Moreover, if you have the resources in place to train your users how to use features like alerts, Office integration, and views, then there’s a great deal more that SharePoint can do without requiring developer intervention.
SharePoint isn’t just an application, it’s an enterprise development platform. (Yes, I realize that’s a horrible meaningless string of buzzwords.) It provides many of the building blocks that most corporate applications need, but it’s up to your team to know how to configure these features, how to make them work together, and when to cross the line and start writing code. If your company doesn’t approach it that way, then it’s going to be a time sink.
I can’t really speak to the “large application” side of the equation, because the most I’ve done to extend SharePoint is write a couple of web parts. However, I can see the potential value in the right set of circumstances.
Overall, SharePoint just doesn’t seem to be the right tool for mid-sized applications. It’s very flexible with very little configuration on the low end of the spectrum. Conversely, there are a lot of good features companies can utilize if they have the development resources to focus on it. But between the two lies much kludging and hacking.
The trick is determining when the application is too big or small for SharePoint to be a worthwhile option. And that ties into my plan for my next post on the subject (whenever I get around to writing it): misconceptions about SharePoint. (Because from my experience, there are a lot.)
Sidebar: My difficulties
If my posts on SharePoint seem to stem from confusion, it’s because they do. There are two other developers in my company, and we’re all wearing a couple of hats. I’ve probably spent the most time working with SharePoint. Because of this, I have to play analyst, developer, and tech support with our SharePoint projects (not to mention my other responsibilities). That’s been fine for smaller projects, but a document management system is far more critical and centralized than department portals. I’d be curious to know what other people are doing with SharePoint, and what a typical team administering and developing a SharePoint site looks like.
In addition, coming from a background of PHP, Python, and ASP.NET, SharePoint is a bit of a philosophical shift. The skill set required for development is vast–trying to read through a book on the subject is overwhelming because there’s only a fraction of it that’s useful in any given case. On the other hand, there’s so much that’s just not clearly documented through MSDN.
1 To be fair, you can query data through certain types of web parts, but you have to use an XML-based language to write your queries rather than SQL. Also, reporting through SQL Reporting Services is a bit of a hack.
2 See Fred Brooks’s essay “No Silver Bullet” for more on this concept. Be prepared to check your rabid developer fanboyism of choice at the door.