SharePoint Myths – Part One

With a software platform as ubiquitous and powerful as SharePoint, there are bound to be some "urban myths" that build up around it.  Here are two of my biggies.  What SharePoint myths do you have in the back of your mind?  Let me know about them and I’ll write about them in future posts.

There is an absolute 2000 item limit in lists

As near as I can tell, this myth traces back to the white paper entitled Working with Large Lists in Office SharePoint Server 2007.  This white paper demonstrates the results of load testing on SharePoint lists under various scenarios, and part of the conclusion is:

There is documented guidance for Microsoft® Office SharePoint® Server 2007 regarding the maximum size of lists and list containers. For typical customer scenarios in which the standard Office SharePoint Server 2007 browser-based user interface is used, the recommendation is that a single list should not have more than 2,000 items per list container. A container in this case means the root of the list, as well as any folders in the list — a folder is a container because other list items are stored within it. A folder can contain items from the list as well as other folders, and each subfolder can contain more of each, and so on. For example, that means that you could have a list with 1,990 items in the root of the site, 10 folders that each contain 2,000 items, and so on. The maximum number of items supported in a list with recursive folders is 5 million items.

This just doesn’t turn out to be true. I’ve worked with lists with tens of thousands of items which behaved in quite a peppy manner, even accessing them with Data View Web Parts (DVWPs).  There is also a possibility of indexing various columns if that matches your use cases, as Woody Windischman recently blogged in his Indexing SharePoint List Columns post.

The key phrase above is "use case".  If your use cases dictate that a list with a million items be sliced and diced on a public Intranet ecommerce site’s Home Page, it’s very different than if the occasional item needs to be viewed by a user or two.  Make sure that you understand what *your* use cases are and test them out.  Stop thinking and saying that there is a 2000 item limit; just use that number as a guideline where you might want to think about testing further.

You have to write "code" to get anything useful to happen

I think that SharePoint demonstrates the 80/20 rule very well.  It does so many things, but for most people, not quite exactly as they want.  Is it good enough to solve 80% of the problem, though?  I would argue yes.

With newer platforms like SharePoint, the old rules don’t, and shouldn’t, apply.  "Development" cycles can be measured in weeks, not years.  True collaboration is something that many people just don’t really understand well.  Will taking a very long time to get the technology exactly right solve that?  Nope.

So stop thinking traditionally about having to write a lot of code to get things done.  There are three tiers where you can accomplish things with SharePoint:

• First Tier: Through the UI.  It’s unusual for an application or development platform to provide so many customization options simply through the UI. Use them first!
• Middle Tier: SharePoint Designer and scripting in Content Editor Web Parts (CEWPs).  Yes, you manage CEWPs through the UI, but since I’m talking about script, I put this work in the middle tier.  You can (and I prefer to) also do scripting in SharePoint Designer and embed it in the pages rather than in CEWPs.  DVWPs are so powerful, that you can do virtually anything you want with them.  You can also develop quite sophisticated workflows in SharePoint Designer.
• Third Tier: Visual Studio for managed code.  Believe it or not (and here’s one of my little secrets), I’ve never needed to write a custom Web Part in Visual Studio.  DVWPs server me just fine, thank you very much.  On the off chance that you need to make a Web Part bulletproof, use a DVWP at least to prototype it before you hand it off to the coders.  You may never even need to get to that step.

An environment like SharePoint is groundbreaking enough that people may struggle with how to think about it in your organization.  Get some quick wins out there fast with simple UI configuration and Middle Tier development.  You stand a much better chance of success.