SharePoint Development vs. Configuration

(This article was originally posted on http://furuknap.blogspot.com/2009/11/sharepoint-configuration-vs-development.html)

SharePoint's greatest feature is the ease with which end users with little or no training can add or modify existing features to make SharePoint do what the user needs. However, there are downsides to this feature if you are not careful, and you cannot really expect to harness the full power of a platform such as SharePoint with nothing more than a cursory knowledge of clicking links on a web page.

In this short article, I'll explain the differences between the configuration approach and the development approach. I'll tell you about the benefits or each and also the downsides. This will help you understand the two approaches to making SharePoint do what you want.

Configuration
The first approach is where users through the web interface or other tools create content and organization themselves. The user simply adds or modifies lists, content types, pages, activates or deactivates features, makes configuration changes, and boom, you have a fully customized solution, tailored to the user's need.

This method of development is called customization or configuration. You don't actually create anything, you simply utilize what is already there and customize new lists, pages, or other artifacts to create a solution. End users love this method. They are themselves empowered to utilize SharePoint features, and offers them a chance to get just the functionality they need.

Taking everything up one notch, users can use SharePoint Designer to get even more power. With little or no training, users can create new pages and workflows, set permissions and options, customize forms for individual lists, libraries, or content types, and generally go bananas much to the concern of administrators and developers.

The true beauty, however, is that those who know how they need to work are the ones who are empowered to model SharePoint into exactly what they want. Department managers can create workflows that are unique to them, or set up reports to display exactly the kind of data that the department needs. End users can customize the workflow when it starts or tailor their own view of the reports, and no one needs to write a single line of code.

Regardless of how good a developer is, he or she cannot possibly know everything about how every employee wants or needs to work.

What's the Downside?
First of all, it is very difficult to maintain a coherent solution in the long run if users are given free reigns to do whatever they please. Without control, many argue, it is impossible to support a SharePoint solution as you do not know what you will face when a user calls for help. If you're a developer, ask yourself: How will you upgrade a solution if you have no idea what is in that solution?

Second, the options available for configuration are limited by nature. Someone has to create the lists that the user will then customize. True, SharePoint does offer a wide variety of lists, content types, and other elements out-of-the-box, but users more often than not end up wanting more. Something as simple as a customer list or a list of products does not come out of the box and will have to be created.

Third, changes made using the configuration method are not easily reproduced. If one department creates an excellent solution, you can't just take those components and reuse in other parts of your SharePoint farm. To some extent, you can create templates as an end user, but these templates are ‘locked' once you create them, and even if you can create new templates in a flash, there's no way to affect existing sites or list when you update a template.

Paul Culmsee wrote a very nice article on SharePoint templates vs. definitions, by the way. I absolutely love that guy's writing style.

Finally, some options are simply left out of the configuration method altogether. You cannot add new application pages using configuration, for example, nor can you add new functionality that requires the use of compiled .NET assemblies, such as web parts, event receivers, or some types of workflows.

Professional SharePoint developers and administrators often shun this configuration approach and as a result often attempt to reduce the number of options available for the end user. Some go as far as locking everything completely down, effectively killing one of SharePoint's strongest features.

If you want to learn about configuration of SharePoint, you should visit EndUserSharePoint.com.

Development
This is where development comes in to save the day, at least from the point of view of the developer. The power developers have is far beyond that of configuration. Developers can do anything you can do with configuration and then far more. Want to add behavior to your solution using workflows and event receivers? No problem. Want to create new web parts or controls on a page? You can do that. Need to create a completely custom provider for the navigation of a solution? Well, with code you can, whereas for configuration, you can't.

Not just can SharePoint developers do a wider array of tasks, but they can also affect entire SharePoint farms in a single swoop, where web interface or SharePoint Designer configuration may take days of manual work. With a few lines of code, a SharePoint developer can add a new column to every content type or list in a site collection, and just as easily change the name or configuration of a web part throughout the organization.

The maintenance and reuse aspect is also a breeze for the SharePoint developer. Not only can they easily reapply their solutions anywhere in the farm, they can also upgrade existing solutions so that they can fix minor issues rather than having to recreate everything. There are certain things that cannot be upgraded, but compared to configuration where you cannot widely upgrade almost anything, this is a major benefit.

With all that power, it is not strange that many developers feel a bit like gods; they have the power to do anything, and looking down on ‘mere end users' is sadly an often practiced sport.

What's the Downside?
However, developers trade time and ease for that power, for developing SharePoint solutions takes a lot more work than simply hitting Create every once in a while. Of course, with that added time and complexity, you may not want to do much development work at all, or at least the cost will be prohibitive for any small updates. There is always a certain overhead in starting a new development project, and you need to either employ or hire people with the right skill set.

Of course, if you have a lot of experience or use the right methodology, you can greatly decrease the effort of SharePoint solution development. The answer is 42, by the way, and in a later blog post, I'll tell you more about the 42 lines of code that will save your SharePoint development projects.

Then, there is the battle of working around certain limitations of SharePoint. For example, if you have deployed a solution, you cannot add new features of files during an upgrade. This won't change in SharePoint 2010 either, so in order to build on your solution, you need to deploy new solutions and ensure that you activate the features of that solution throughout the farm.

Neither can you change a site definition after you have made it the first time. This is a great problem for many; you may be working on a huge project in which there are dozens of site definitions. You need to get them all right the first time around or you need to maintain dozens of configuration files, two per site definition in fact. Regardless, you can make no mistakes, or you need to start over with a new site definition, even if you do something as simple as misspelling the name of a list.

If you want to learn about SharePoint development, make sure you chech out Beginning SharePoint Development

Is There a Point to All This?
We seem to have two very powerful methods for making SharePoint behave, but they are seemingly incompatible. An end user wants a quick result with minimal effort using configuration and can whip up a new solution within minutes, while the developer wants to think ahead and make sure the changes are reusable and that they can be recreated or maintained using best-practices method for development, source-control, testing, and such.

The point here is that you need to find a balance between what power you afford the end users and what must be created using development to ensure reusability and upgradability.

The sad fact, though, is that if you are to have any chance of going beyond these limitations of SharePoint, you need to use code. Creativity using configuration will only get you so far.

.b