Microsoft’s technology stack has traditionally offered a lot of good options leaving the developer or architects to choose the best path. Even still there there have been people camping out on one side or the other. In the early days when VB first came out the hardcore devs didn’t take it seriously, and I remember hearing a lot of negative comments from traditional C++ developers. VB devs didn’t have to understand concepts like threading and memory allocation and the VB code was bloated leading to “poor performance.” While those statements are true, not every deliverable has the same grade requirements and in many cases businesses were more than happy with the code that was delivered faster and for less money than what C++ developers could provide. I think this is a very good analogy to the current SharePoint development and customization paths. Microsoft has worked hard to position SharePoint as a tool that can be leveraged and customized by power users as well as developers. I think this is both a strength and a weakness; a strength because there are options, but a weakness because many of the people doing the work do not understand the implications of their decisions.
Understand the Scope of the Solution
The first thing I think about when I get a request is the scope of the solution. I think through the questions below and choose a direction that makes sense in order to meet the requirements in a cost effective manner.
Who is the audience? – The larger the scope of the audience, the more robust the solution should be. A solution created for a work group is probably very different than one used enterprise wide.
How many users will need to use it? – Similar to the previous question, but a little more concrete. Do you expect 10 concurrent users, 100 or 1000? Company or enterprise wide means different things in different environments.
Where will the solution be used? – Deploying the solution on a single Project or Team Site is very different than deploying it to 100 sites, which is very different than deploying to the front page of a company’s Intranet. If it is for a single use the Light Dev and Customization path can make sense. If it is meant to be reusable, then it warrants more time and attention to make sure that it is the best it can be. If it is use on a top level or heavily used page or site then performance is even more critical meaning a more robust solution should be developed.
How long is it expected to be in use? – Try to have some understanding of how long the solution is intended to live. Assumptions may change, but make an informed decision based on the information you have at the time. If a newly acquired third party tool will be providing that functionality in the next 10-12 months there is no need to overbuild the solution. Likewise, don’t take short cuts on a critical project that can undermine peoples’ understanding of the capabilities of the platform.
Who will maintain the solution? – This is a tricky one. Not every company has a large staff of qualified developers waiting in the wings. There is normally a large backlog of work waiting for them. If you are a consultant then you might look at whether you are handing over the support to the internal team or if your group will continue to maintain it. The group isn’t capable of maintaining a solution and doesn’t have the tools and environment in place to do the work then full scale development may be a bad idea.
Are there performance requirements? – If there are performance requirements then those should be planned for from the start. Stats like page load times, and an agreement on what constitutes the end of a page load are important. In most cases I have not seen this requirement.
Light Development and Customization
Light development and customization includes features and solutions dealing with SharePoint Designer, DataViews, Content Query Web Part and the Content Editor Web.
More than anything I see this being for the benefit of Power Users and site owners who can apply customizations within the scope of a site collection. While there are many that want to outlaw SharePoint Designer and these solutions in their environment, I think they risk eroding the value and impact of their SharePoint platform. I see SharePoint as a tool that enables content/site owners without needing to rely on a central IT group.
I tend focus on this part of the stack when dealing with solutions targeted to small teams or with small requests that do not need a full blown application. There are definitely lots of opportunities for simple, high impact, one off solutions.
This however is probably not the appropriate set of tools for org wide workflows, complicated forms, or even displays on heavily trafficked pages. The Content Query Web Part (CQWP) for example is not the most efficient way to aggregate content so pulling something like project status information from 50+ project sub-sites is likely to end in frustration.
Robust development includes features and solutions dealing with Visual Studio built applications packaged and deployed via the solution framework in SharePoint.
This really should be the starting point when reviewing any project of real significance. The developer has a lot more flexibility and control in what can be implemented and it is much easier to centrally track and manage what is deployed to the server.
I think that it is important to note that poorly developed VS solutions are at least as dangerous as anything that can be done using the Light Development and Customization technologies and techniques. Failing to dispose of objects or inappropriate CAML queries can bring down a server or cause all kinds of havoc.
There will be times when it is necessary to blend the two approaches. Within a given project there are features that are core to the solution and some that are in more of a supporting role. Admin or reporting features are a good example of that, where using a DataView may be easier to maintain than a custom Web Part to display content.
The Business Does Not Always Understand
Customers, project stakeholders, and other decision makers do not always know what is best. I’ve seen many cases where even sophisticated development shops do not fully understand SharePoint development paths and fully leave the decision up to the developer. Like any project using any technology, risks should be identified and discussed before things get too far. It is irresponsible to deliver a solution that you know cannot be supported or maintained after you sneak out the back door at the end of the engagement.
From an administration perspective, I do not want to manage more solutions than I need to. There is a balance between wanting to know what is deployed to the environment and wanting to touch everything that is installed. If there is a fairly ridged change control process in place it can be time consuming to submit and deploy minor updates to small, narrowly scoped solutions. Again, my approach comes back to the scope of the solution preferring to focus on widely scoped, high impact solutions.