SP2010 solutions can be developed by users with a wide range of skillsets

Question

Proposal: SharePoint Overflow

I think that a site driven by user questions will provide better coverage of the possibilities of SP 2010. There are too many blogs on the Internet that solve every SP 2010 problem by opening Visual Studio and guiding the reader through some C# code.

In fact, SP 2010 has a number of other ways to develop solutions that are geared to a variety of different levels of technical competency. I think that this style of Q&A site will draw out more of the variety of ways to solve a problem and document the tradeoffs of different solutions.

In particular there is a hugely powerful middle tier available in SP 2010 where you can build solutions using Javascript, JQuery and the SP 2010 Client Object Model. The same Client Object Model is available to .NET applications on the client, and not just C#. For instance I build a clientside solution using IronPython and the Client Object Model.

In large enterprises where SP 2010 seems to be finding its core market, better documentation of this middle tier will unleash hordes of new developers who simply don't have the time to delve into the mysteries of C# and who wouldn't get permission to install their code on the servers in any case. But they can leverage Javascript, JQuery and the Client Object Model which is available to both Javascript in the browser and .NET on the client.

Answer 1

You should also give a mention to SharePoint Designer.

As powerful as it was in 2007, in 2010 it has came on leaps and bounds in terms of power for the true End User (one who doesn't know any code in any language) - External Content Types can be created right out of SPD, Workflows are far more powerful than they ever were without firing up Visual Studio.

I'm a hardcore C# coder myself, but I definitely appreciate and understand the capabilities of SharePoint Designer 2010 - particularly the power it gives the end users, so this has to be taken into account when considering what "out of the box" solutions you can build (referring to the Composites workload of the "SharePoint Wheel"), before even considering JavaScript, jQuery and the Client OM.

Additional: Adding onto my original answer, you mentioned something about "coders who might not have permission to deploy code"... Well this changes entirely in SharePoint 2010 - with the Sandboxed Solution.

Power Users in an organisation can write solutions that deploy a wide range of things, including Site Columns and Content Types, C# assemblies (including web parts) and many other things, but uploading to the site collection solution gallery. There are limitations with Sandboxed solutions - which those of us in the field are very aware of but this is another area which the wider population should know to consider in terms of what solution they use (in a scale going from OOTB UI -> SharePoint Designer -> jQuery/JavaScript/ECMAScript middle tier solutions -> Sandboxed solutions -> Sandboxed with ProxyOperations -> Farm Solutions0.