Sunday, February 5, 2012

SharePoint Development - People

Once an organization has made a decision to develop on SharePoint (see The Decision to Develop on SharePoint), it's time to start putting into place the necessary infrastructure. This blog post will focus on the People considerations. Future posts will focus on Process and Technology. Note that this post is part of a series of posts on the topic of setting up an organization infrastructure that supports SharePoint development. Here are the parts to this series (this post is part 2):
The traditional stereotype of a software developer is that that they are antisocial nerds. The problem with this stereotype is that while likely applicable at some point in the past, today it is largely untrue. A study in the Global Journal of Engineering Education of Cuban software developers demonstrated that, among the sample population, 26% of the developers were ESTJ on the Meyers-Briggs scale:

Compare this to 8%-12% for the general population in the United States (from Wikipedia):

This implies that software developers are largely more outgoing and task oriented than the general population. While the study was only Cuban software developers, I would expect that populations of software developers would have a similar profile.

Nowadays, software development is very much a collaborative effort, which means that developers have to have social skills that facilitate communicating effectively and efficiently with all interested parties. Microsoft Research has done some work on this. Their article on Human Interactions in Programming states that "software development is done by people working together." The article goes on to emphasize the collaborative nature of successful software development.

When setting up infrastructure that supports SharePoint development, an organization should strive to find outgoing, well-adjusted, experienced developers and give them the the tools and resources they need to work in a highly collaborative environment.

Grady Booch, one of the creators of UML (Unified Modeling Language) is credited with coining the term "Collaborative Development Environment" (CDE). Generally considered an evolution from the Integrated Development Environment, a CDE is a seamless integration between development environments, communication tools and collaboration tools that all the involved parties can use. It applies specifically to tools but can be extrapolated to the entire way of working for a developer. On any given project, a developer may make thousands of tiny decisions that aren't documented but may (taken together) affect the overall outcome of the project. In order to facilitate a process that helps developers make decisions that meet or exceed the goals of a project, organizations should support and encourage strong communication ties (physical proximity, instant messaging, screen share, video conferencing, etc...) not only between each other but also between each other and the end users. A strong feedback loop is critical.

So what does all this mean?

Ideally, for any given project, there is a team of resources 100% dedicated to the project, all sitting in an open work area together collaborating to achieve project goals. To maximize the chances for success, the team should be made up of a diverse group of smart people that can communicate effectively and efficiently. Interestingly, although to this point I have cited nothing about process, we are starting to venture into the sweet spot for Agile, which will be covered in the next post in this series.

Technical Proficiency
SharePoint development generally requires a diverse set of skills. It's important to remember, however, if an organization has a highly collaborative environment, not every developer has to have all the skills. In fact, on some projects, it is impossible for one person to have all the required SharePoint skills for the project.

Eric White from Microsoft details the comprehensive set of developer skills for SharePoint 2010 in a two part article. Here is a link to part 1: For convenience, listed below are the technical skills I've identified that are important for SharePoint 2010 developers. Note that these match up pretty closely to to Eric's article but for a more thorough explanation of the skills listed, please see Eric's article:
  • C#
  • LINQ (and CAML)
  • WCF
  • ASP.Net
  • html/CSS
  • javascript/jQuery
  • REST
  • SharePoint Client Object Model
  • Silverlight/XAML
  • PowerShell
It is important to understand that, in many cases, the skills will be divided among multiple people. One logical division is client-side skills vs server-side skills as follows:

In addition to the technical development skills, however, a developer needs to understand various components of the SharePoint architecture. The following article from Ricky Kirkham of Microsoft does a good job of outlining the SharePoint 2010 architectures: Again, for convenience, I listed the ones I think are important.
  • Authentication & Security (WIF, Directory Providers)
  • Search
  • Services (User Profile Synchronization, Excel, Access)
  • Workflow
  • Business Connectivity Services and Business Intelligence
  • Social Collaboration
  • Governance
  • Disaster Recovery
  • Taxonomy
Once again, in many cases, the skills will be divided among multiple people.

When building a team of SharePoint 2010 developers, you want to setup a collaborative environment and hire outstanding communicators that can work effectively and efficiently in that environment. In addition, the developers should have a strong mix of technical skills and understand various components of SharePoint architecture. Easy, right?

In the next post, I will focus on process. You have made your decision to develop on SharePoint and have hired the right people. Next it will be time to talk about how they will get the work done.


  1. Doug:

    This is a great summary of the skillsets and capabilities that a Sharepoint development team needs.

    I think that the way you stress the fact that these skille may be found across a set of people is important, but the converse is also true: you don't need one person per skill. I see organizations making this mistake all the time, a la "We need a jQuery person" instead of "Who on the team knows jQuery?"

    Another thing I see is that the idea of collaborative development still hasn't become mainstream, but it's absolutely critical for a platform like SharePoint. Too many organizations still treat SharePoint like any other software without realizing the types of interactions that the developers ought to have with the users. IMO, the development should not be separate from the users; there should be a dedicated team of people with all of the skills required for collaboration to be successful with all required disciplines represented - that means techies and business people working hand in hand.


  2. That is a great comment Marc. Thanks for adding your valuable insight.

    I might have a People part 2 blog to discuss some hypothetical teams for readers to get an idea of how a SharePoint 2010 project could be structured.

    I agree with you that people say "We need a jQuery person" or a "search person" etc... The reality is that people have a different mix of skills and, more importantly, a different capacity to learn different skills. A developer who is 9/10 in C# (in terms of skill and knowledge) might be a 2/10 in jQuery, but give him a week or two and he might he easily become a 6/10 in jQuery. 6/10 may be adequate given the project requirements and assuming there is time to traverse the learning curve. I often see extremes on both ends. "You don't know jQuery...then we need to find someone else." or conversely, "You are the developer, go setup an extranet for our 500 clients." The reality is that there are so many shades of gray it's almost hard to fathom.

    I also agree with your comment about the interactions developers ought to have. I often see a pattern something like this:

    User expresses need --> Management recognizes need --> Requirements are written --> Developer develops-> Business Analyst ensure requirements are met --> User gets need met (maybe)

    I will talk more about process in my next post, but this is a high-level waterfall-like approach. I find myself consistently pushing for developer/user interactions, preferably in person sitting right next to each other. Although admittedly extremely high level, I would put it more like this:

    User express need --> Management prioritizes and approves a problem-solving approach --> user, developer, and business analyst create and implement solution.

  3. Hello, It's a very nice blog but...

    My point of view as a SharePoint Development is that SharePoint is pretty much all about the lists since it's where the data is kept. How you choose to develop and set up SharePoint is a bit up to yourself as a developer. Some developers love their XSLT and some are more into custom built web parts deployed directly into the GAC. I'm one of those GAC dudes.


  4. SharePoint Server 2013 provides a comprehensive solution for connected information work,that enables people to transform the way they work while preserving the benefits of structured processes, compliance, and existing IT investments.