So after day 1 and day 2 of the Conference I am ready to share some of my initial thoughts.  In the work that I do there are two big issues that customers struggle with in making effective use of SharePoint inside of their organizations.  Honestly there are many more then two, but I am going to address two of them in this post. 

SharePoint Development is Software Development

The first is treating code that is developed in and for SharePoint like a real software project.  All too often we see customers doing development and customizations in production because it is perceived to be so hard to move code between environments.  The solution to this, of course, is to write Features and deploy using Solutions.  However, the developer has a problem.  They have to do their development (usually) on a Virtual PC that is isolated and usually running on their desktop.  This solution is great in that the isolation makes it very useful for their development of code, but makes it hard to ensure source control of that code, and hard to debug outside of that development environment.

SPS2010 will address this in two ways.  First developers will now be able to run SPS2010 in a developers mode natively in Windows 7 or Vista.  This still gives them the correct level of isolation, but also makes it easier to link to source control.  When you throw Visual Studio 2010 into the mix it gets even better.  I saw a demo where the user can create myriad types of SharePoint projects from templates in VS 2010 and with a single checkbox ensure that it is stored in TFS (or the new TFS light).  One other nice point there is that most of the add-ins that we strongly recommend to people (such as the WspBuilder Add-in for VS2005/8) are now baked into VS2010.

The second major improvement for developers that addresses issues that we have struggles with is the ability to debug.  Its easy to do it on your development VPC, and usually the Integrated Dev environment will have VS loaded onto it to assist with debugging in that environment, but QA and Production do not need to have and should not have VS loaded onto them.  This makes figuring out what is actually happening pretty difficult in those environments and usually involves a lot of log file sifting to try and find what is going on and how to resolve it.  One part of this solution is the inclusion of a correlation GUID with errors that are presented to users.  This way the end user can send you a screen shot and it will have a GUID on it that you can then find (hopefully) in the log files and that should assist greatly in finding out what the problem is.  The second thing I saw was a web based stack tracer (similar to the ASP.Net Trace page directive) that provides a wealth of information about a page that has been loaded.  I am not sure if this can be turned on without having to attach VS 2010 as the debugger, but if it can it might very well be the solution to the problem of debugging in Production.  One very neat feature…it shows how long each item in the call stack took to execute thus making finding out what it making your page load slowly much easier.

Building a Corporate Taxonomy is critical to “Findability”

A while back Bill English gave a presentation for SASUG on Findability and one of the key tenets is that without accurate tagging of documents with Metadata you will have a hard time finding them when you need to find them.  SPS2010 offers a very nice set of features that will assist with this.  At the heart of it all is a Managed Metadata Service.  This is a Farm level service that will let you create a set of hierarchical taxonomies that can then be used throughout the organization.  A site can subscribe to one of the taxonomies (and so can Content Types) and then users will have the ability to pick the tag from that taxonomy using a tree style picker.  Then users can also use this same taxonomy to look at Lists and Libraries and “navigate” through the set of items.  Its very fast and makes management of large document sets much easier.

These taxonomies can be set up with synonyms, and also can be set up to allow end users to add new items and levels so if the corporate taxonomy is missing a branch or a leaf to the tree the end user can add it.  Then the corporate taxonomist can later include this into the official taxonomy.  Local sites can also declare their own taxonomies for use just in their site as opposed to being limited to using only the corporate taxonomy.  Lastly, the Metadata Manager Service allows for taxonomies to be exported/imported to facilitate movement amongst multiple farms (either from Dev/Test/Prod, or if you have multiple Prod environments)

There is a ton more but that is all I have time for this morning.