What would you say are the primary strengths and weaknesses of OOTB customisation vs. SPD vs custom code?

This one is definitely going to take more than 140 characters so here goes...

Out of the box (OOTB) customisation allows any end user familiar with SharePoint to create sites, lists and web parts through the user interface to produce something that meets their specific requirements.

Strengths -

Very quick to create customisations

Anybody with basic SharePoint knowledge can do it

Forces users to create solutions in a "SharePoint way" which encourages consistency

Weaknesses -

Doesn't provide much flexibility - compromises have to be made with requirements

If you want to repeat the same customisations again then options for recreating the solution are limited - manual repetition of creation steps or templates

SharePoint Designer (SPD) customisation allows power users to get a bit more creative and make use of some of the more advanced options in SharePoint such as custom workflows and connecting to differnt data sources.

Strengths -

More options for customisation - will fulfill more of the original requirements

Make changes to master pages and page layouts - create a completely new look and feel

Weaknesses -

Difficult to deploy customisations made using SPD to other sites - eg. A custom workflow created in SPD is applied to a specific list and cannot be resused on another list. The only option is to manually recreate the workflow again for the next list.

It is possible to do a lot of damage very quickly if put into untrained hands

Once files are customised by SPD they cannot be changed by custom code

Custom code requires a SharePoint developer to write it but it is the most powerful option that opens up the full SharePoint API, web services and any other code you want to use to customise your solutions.

Strengths -

Provides the most options for customisation

Customisations can be packaged up as features that are easily deployed and reused in multiple solutions

Deployment can be controlled and governed more easily as customisations can only be deployed by people with SharePoint admin permissions

Weaknesses -

Requires a SharePoint developer

Takes longer to achieve the same results

The above lists are a very brief summary of the pros and cons for each option. In reality it would be possible to have lengthy discussions about each but I think these lists provide a fair summary that should help as a primer for the more important discussion - which option should I choose?

As with most decisions like this the short answer is - it depends. In this case it depends largely on the trade off that you are prepared to make between speed of solution develoment and flexibility/meeting the original requrements exactly.

If you need something fast and are prepared to compromise by not meeting the original requirements 100% perfectly then OOTB is the way to go.

If, on the other hand, you need to have a solution that ticks off every requirement perfectly, that can be easily reproduced across lots of sites and you are prepared to wait a bit longer for delivery then custom code is the answer.

SharePoint Designer is a middle ground that combines the best and worst of all the options. In my opinion it should only be used to quickly prototype something that you later turn into a well packaged custom code solution or where you have to customise to meet a requirement but do not have SharePoint development resources available.

In the interests of full disclosure I am from a SharePoint development background and have also spent a significant amount of time working with SharePoint whilst being constrained to only using OOTB customisations. As a result I am not what I would describe as a typical SharePoint dev - ie. Reach for Visual Studio first and ask questions later!

This may sound like a betrayal of my SharePoint developer brothers and sisters but I would argue that custom code should only be used once you are sure that what is being asked for cannot be achieved using OOTB customisation. That may sound obvious but it is easy to take requirements on face value and assume that what the end user is asking for cannot be compromised on which makes it look as though custom code is the only option. In reality if the end user understands that they can have a solution that meets 80% of the requirements delivered in 2 days using OOTB or a solution that meets 100% of the the requirements in 10 days using custom code those requirements that were previously set in stone suddenly become a bit more flexible.

So in summary, and just to be clear so I don't get flamed by all the SharePoint devs, custom code is great. It provides the most number of customisation options that can be deployed to your SharePoint farm in a repeatable and controlled way. However, I would choose OOTB wherever possible in the interests of speed of delivery and productivity even if that means using your powers of persuasion to talk the end user into settling for a solution that doesn't tick off 100% of the original requirements but does meet the core ones, they will thank you in the end!

When Microsoft Office SharePoint Server 2007 was in beta, and for some time after it was given a full release, the level of support and documentation available was, at best, pretty sketchy. Over time Microsoft have improved what is available on MSDN and Technet as well as publishing best practices but what really saved MOSS 2007 and the people who work with it was the SharePoint community who have done a great job in supporting each other with blog posts, forums, wikis, white papers and the like.

Given that history, it is fantastic to see the amount of information being made available before the public beta of SharePoint 2010 is even released. As the NDA on SharePoint 2010 was lifted at the SharePoint conference in Las Vegas there was a veritable blizzard of blog posts from various SharePoint insiders.

Another brilliant developer post on the factors that could persuade asp.net developers to start using SharePoint comes from Jeremy Thake the man behind SharePoint Dev Wiki. This is a wiki that was started as a reaction to the lack of a definitive resource for SharePoint developers and has become the place to go for reference material and guidance on SharePoint development. The site has now been extended to include a SharePoint 2007 Administration wiki and a shiny new SharePoint 2010 Development wiki which is already starting to be filled with content.

A communication method that wasn't available when the 2007 version was released was Twitter. Not being able to go to the SharePoint conference was frustrating but Twitter came to the rescue and at times it was almost like being there. Well, ok, maybe not but it did provide a rich stream of information about new features directly from the people who were lucky enough to be there. This allowed the people who couldn't be there in person to get a glimpse of some of the detail being revealed during the sessions and to see beyond the headlines of the keynote.

Back in the beta days of SharePoint 2007 it was often a case of feeling your way and piecing together bits of information from lots of different sources to achieve the end result you were looking for. I think I can say with some confidence that those bad old days are in the past for SharePoint. It is now a huge success story for Microsoft and they are supporting it better than ever with documentation and tools. In addition the community of people working with and supporting SharePoint has grown massively over the last few years and this is where a lot of the best content is going to come from. This time round the problem won't be the lack of information the issue will be that now the trickle has turned to a flood can we keep up with all the content being produced? This is where inititiatives like Dev Wiki can really help to put some structure to that content and also allows us to give authority to the best bits.

Have you come across any other great SharePoint 2010 posts that are worth sharing? If so please add them in the comments.