- Part 1: The Decision to Develop on SharePoint
- Part 2: SharePoint Development - People (this post)
- Part 3: SharePoint Development - Process (coming soon)
- Part 4: SharePoint Development - Technology (coming soon)
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.
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: http://msdn.microsoft.com/en-us/library/gg454784.aspx. 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:
- LINQ (and CAML)
- SharePoint Client Object Model
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: http://msdn.microsoft.com/en-us/library/gg552610.aspx. Again, for convenience, I listed the ones I think are important.
- Authentication & Security (WIF, Directory Providers)
- Services (User Profile Synchronization, Excel, Access)
- Business Connectivity Services and Business Intelligence
- Social Collaboration
- Disaster Recovery
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.