A: SharePoint is a mammoth product with many features and many avenues of development and it can be quite intimidating when attempting to understand the entire framework. The learning curve can be substantial because SharePoint is dependent on server environments. Developers are not always used to working with and managing servers to the extent a SharePoint developer is required to do. The following table outlines key SharePoint skills that developers should have:
|
Essential SharePoint developer skills |
Hands-on awareness |
Awareness |
|---|---|---|
|
CAML |
SQL Management studio |
Firewalls |
|
.NET development (C# or VB.NET |
Visual Studio 2010 |
Exchange |
|
Master Page, HTML, CSS, and JavaScript |
Virtual Machine (Hyper-V or VMware) |
SQL Database Mirroring |
|
Web Services, WCF Services | ||
|
Deployment with Web Solution Packages (WSP) and SharePoint Features |
In the previous table, the skill Awareness such as for firewalls and Exchange, is more about being aware of the functionality and implications, rather than having access to this technology to make changes.
Before development can start, a developer needs to understand the SharePoint framework. Framework is a fancy way of saying SharePoint out of the box functionality.
If a developer is asked to build a custom workflow, he/she will first have to understand the bigger picture of requirements, such as:
- What a workflow looks like inside of SharePoint
- How users interact with the workflow
- Workflow steps
- Other concepts such as sites, lists, document libraries, list items, and content types
This knowledge is vital, so they can leverage the SharePoint framework and not build new .NET functionality to duplicate already existing SharePoint functionality.
Note
The moment the solution requires .NET development, it is a development project and there are additional complexities involved, such as source code maintenance, small requests, and environment stage releases. If this workflow can be built with SharePoint Designer then the go live date may be sooner. What you do not want to do is start the workflow deployment with SharePoint Designer and realize that the available functionality cannot meet the requested functionality and have to start from scratch.
A developer needs to understand the pros and cons of each development path in order to make sound decisions about the customization. Once the developer makes a decision about the development path he/she might need to learn how to use development tools such as InfoPath 2010 and SharePoint Designer 2010.
Note
A common mistake that developers often make is that they only look at the end point of the solution, rather than the SharePoint components and the path to reach this endpoint that are required for the solution, such as infrastructure, user base, or integration. So a holistic approach is essential. This development planning approach is not unique to SharePoint and this is key to a successful deployment.
Infrastructure technologies such as Active Directory and IIS go hand-in-hand with SharePoint development and can also prove to be quite a challenge. The average newbie developer doesn't work at the infrastructure level of development so they are unequipped to deal with issues that arise.
A SharePoint developer needs to understand the configuration of servers in order to develop for SharePoint, be in tune with how customizations will behave inside a multi-server farm, and know where to look if they exhibit unexpected behavior. Part of the SharePoint infrastructure is SQL, and the beginning developer will need to understand some basic SQL management, configuration, and security.
SharePoint developers need to be "big picture" focused and beginners can be unprepared to work at that level. The typical ASP.NET development team consists of a mix of junior, intermediate, and senior developers, all of whom have different responsibilities. Although the roles might be similar in SharePoint development, the responsibilities are definitely not.
A junior developer is rarely asked to deal with architecture, infrastructure, or deployment. These are mainly an intermediate or a senior developer's responsibility. In SharePoint development, we all need to understand it all at once and right from the start. Some developers, specifically beginners, struggle not only with development but also with testing, deployment, configuration, end user testing, and quality assurance, and overall functionality. SharePoint developers need to "wear different hats" depending on the situation. They are part developers, business analysts, architects, and infrastructure specialists. Although developers may also need to take on different roles, it is not as common, especially as a beginner, and dealing with all of these facets at once is also a unique challenge.
The role of wearing a good business analyst hat is essential; most often it is also likely the hardest role for a beginning developer.
The geeks need to have interpersonal skills (God help us here), but it is rare to find a developer with both technical and business analyst expertise. Yet this combination of skills is crucial for a SharePoint developer because all custom development directly affects end users. It is very rare that a SharePoint developer can focus on a development task that is disconnected from end users. A development team can help alleviate this challenge by distributing responsibilities, but there is no escaping from the fact that all SharePoint developers need to wear multiple hats and have a team approach. This challenge is discussed further in Chapter 7, Growing SharePoint Capacity and Meeting Staffing Resource Needs.
Beginning SharePoint developers face several roadblocks but they can be overcome. If the developer has the hunger and drive to learn new skills, he/she can make his/her way over the steep learning curve. Although no one person can completely master all of the skills SharePoint requires, motivation, ambition, and humility will help the beginning developer overcome his/her initial discomfort in order to navigate the inevitable roadblocks ahead.
A: In the attempt to provide value by delivering customizations, a developer may take shortcuts on setup that have significant impact later on. There is a reasonable amount of setup required for SharePoint development and developers should appreciate the importance of taking the time to configure the development environment.
Typically, a beginning SharePoint developer will deploy a customization to a target test or production environment and after the customization fails will say, "But it worked in my environment." That developer has failed to identify that the two environments are not the same.
Before any development takes place, the infrastructure group must take the time to set up an environment that is similar to the target environment. For example, if the target environment is SharePoint Standard, then the development environment should try to replicate that same environment. If the organization is using SharePoint Foundation 2010 it is no use developing in an environment using SharePoint Server 2010 Enterprise. A development environment will never be exactly the same, but a developer should try to mirror the target environment as closely as possible.
SharePoint is always releasing new service packs or cumulative updates but installing updates might not always be beneficial. SharePoint developers must remember that they are not creating a personal development environment but one that is dedicated to a particular target environment. The developer should make sure to replicate any hotfixes or updates performed on the production environment on the developer environment.
A: One size does not fit all. At times a .NET development can be more appropriate than SharePoint development. You will have to ask yourself, "What are my requirements?", "How many of those requirements can SharePoint out of the box (OOTB) meet?", and "How much effort is included in custom developing the requirements that SharePoint does not natively meet?". The last and most likely the most important question you should ask yourself is, What do I gain from implementing this in SharePoint?
When looking to build a solution you first have to understand the functionality that is required. There are some things that SharePoint does not do well natively and a considerable amount of development will be necessary to achieve the desired results. It might feel like fitting a square peg into a round hole at times. One example is when organizations want to implement a site with the e-commerce functionality. Although it is possible with SharePoint development, there may be other ways to leverage existing .NET solutions on the market. SharePoint does not provide e-commerce features that a SharePoint developer can leverage. In the end, a SharePoint developer will be building all of the components and functionality manually and trying to make them work within SharePoint. If there are no SharePoint features that can be leveraged it defeats the purpose of using SharePoint, and .NET development might be a better option.
At times SharePoint is simply not required and you will have to evaluate the advantages of using SharePoint to build a business case.
One advantage to using SharePoint is that the amount of custom development might be less than building a .NET application from scratch. The caveat is that with SharePoint Development you always have to factor in the cost of SharePoint licenses, server licenses, the resources to manage SharePoint, and the built-in customizations. When you factor it all in, a .NET application might be a better candidate for development.