As a veteran software consultant (in my 20th year), I take pride in not overusing the phrase "it depends." I realize a client works with us because he or she is looking for a solution, and we try to narrow it down to the best solution possible. Unfortunately, working with SharePoint the last several years, I sometimes have to bite my tongue to avoid saying those words. Arriving at the best solution seems to take a little more diligence than before, simply because there are more choices than before. Having choices is not necessarily a bad thing, but having an abundance of choices can certainly complicate things a bit.
There are numerous ways to address many business challenges in SharePoint. There are so many books, so many blogs, and so many experts. Sometimes, the experts seem to contradict each other on what is a best practice. Sometimes, even the Microsoft product teams seem to contradict each other. I definitely have my preferences, based on good and not-so-good experiences over time. I suggest that “best practice” should be used a little differently than it is often used. For example, someone may ask me to identify the “best practice” for surfacing his or her line of business data in SharePoint. Once I have considered the unique business requirements and environment, I will make a recommendation (the best of many considered), then follow best practices to implement the solution.
Some experts will say that it is a best practice to always use Visual Studio to develop SharePoint solutions. They make good points. Some try to do everything “out of the box,” and others favor power user tools, such as SharePoint Designer. My own experiences tell me that it is best to have isolated development, test, and production environments – and I certainly prefer developing SharePoint features as Visual Studio solutions. However, the reality is that some clients have limited environments, no means for supporting Visual Studio solutions, and a propensity for the power user tools. So we use the tools that are the best fit based on the circumstances. If I am using SharePoint Designer, I follow best practices for developing with SharePoint Designer.
Some of the more popular, and sometimes controversial, blog posts and articles on SharePoint are the ones about "what does it really mean to be a SharePoint developer?" and "what not to do on SharePoint." A recent example from my feed reader was this one. The author makes some good points, but as you can see in the comments, there is some dissention. Personally, I think all three points are valid in certain situations. The dissenters think that some of the points are invalid – probably because their situations were different. What this demonstrates is that the best solution is relative to the circumstances, and the best experts are those who have seen the most situations over the longest period of time. I have yet to find a solution that is “always” the best solution, and I rarely say “never.”
A consultant may architect a development approach with the best intentions. The approach may align with your in-house skills, allow for rapid application development, and produce quality code on a consistent basis over an extended time period. Then, three years later, you may be required to upgrade your SharePoint farm to the latest version, and find that all of that code is going to make the upgrade much more complicated because of the way it was implemented. An architect that has gone through SharePoint migrations before may have steered you in a different direction architecturally.
I was recently privileged to hear Dr. Sheena Iyengar speak at a leadership summit. She made the point that the more choices with which you are presented, the better the chance you will make a bad one. So why does Microsoft give us so many choices when it comes to customizing SharePoint? I may have offered fewer choices myself, but let us attempt to address that question.
I want to reference one of the best articles I have come across for identifying and explaining the various SharePoint development approaches. I will almost assuredly reference it in future blog posts. In addition, I want to mention just a few of the factors that I consider when determining the best development approach for a project or project team:
- Are development, test, and production servers available?
- What are the required skills? Are these skills available in the organization for ongoing support?
- What tools does the development team have available to them? What tools can be available if they do not have them already?
- Is this project a good fit for SharePoint in the first place?
- Will this solution scale to the degree needed?
- Is there a third party solution that would add value to this project?
- What is the budget? What is the return on investment? The most affordable solution is often not the best solution, but a solution may often be phased to offset the cost.
There is definitely an approach to determine the best solution. A good consultant keeps an open mind, but also identifies the potential risks based on his or her experience and on the experiences of others. Setting the proper expectations is critical. In my experience, the end result is typically a positive one. Why? As it turns out, having an abundance of development options is vital to SharePoint’s success. Having a trusted partner that understands the options and can work with you to understand which one is best for you, well that’s priceless.