While attending Microsoft TechEd 2012 in Orlando, Florida, I participated in a Birds of a Feather (BOF) session in which we discussed one of the more controversial topics within the SharePoint community: at what point can you call yourself a SharePoint developer?
Defining the SharePoint Developer
The BOF sessions are generally run by members of the community, not with a prepared presentation, but with one or more facilitators opening up discussion on a topic and letting the audience voice their opinions.
These sessions are a great opportunity for Microsoft to sit back and listen to raw input from the community, and are a popular format for TechEd and other events, with many of them recorded and made available for re-broadcast. This BOF session was led by Shannon Bray (@noidentity29), a SharePoint MCM (Microsoft Certified Master), president of the Colorado SharePoint User’s Group, and a senior consultant for Planet Technologies. It was a fairly packed room, and from the beginning people wanted to share their ideas on a definition, or scope, of what it means to be a SharePoint developer.
The question has been at the core of many heated discussions in the SharePoint community partly because of the sensitivity to job titles and formal education path of the engineers who dominate the space, but more so because of the breadth and depth of various SharePoint roles that are beginning to blur the lines between engineer and non-engineer -- from information architect roles, to analysts, to website designers. Some community members even use a term that epitomizes this new empowered user: "Citizen Developer."
The Citizen Developer
Shannon kicked off the discussion with a very simple definition of SharePoint developer -- one which he believes to be accurate: a developer is someone who generates code, uses Visual Studio, or manages their work using some kind of software configurations management platform. While there are developers who work extensively with SharePoint Designer -- a tool increasingly used by analysts and power-users to build and modify SharePoint solutions and sites, it is rare to find a non-developer working with Visual Studio.
Almost immediately, there was disagreement from the BOF participants. There's a reason for this disagreement: as SharePoint becomes more complex and functionally rich, the out-of-the-box (OOTB) tools that come with the platform are also advancing, allowing non-developers (usually the business analysts and support personnel who own the platform) to accomplish more and more advanced actions, such as building advanced workflows, customizing branding, and building out business intelligence and metadata-driven solutions, among others.
Last fall, author and consultant Mark Rackley addressed this topic on his blog, beginning with a statement that yes, it is very important to clarify the differences between developer and non-developer. His most compelling reason for this differentiation: building the right team, with the right skillsets.
What may seem a semantic point to some becomes critical when building out a team to create and support an enterprise deployment that needs to be scalable, performant (my favorite Microsoft word, meaning "sustainable performance"), and in many cases must follow industry and legal standards for development methodology and documentation. Non-developers may be doing miraculous things using SharePoint Designer, jQuery and InfoPath, but they are unlikely to have the education and experience required to ensure long-term scalability/viability. It’s sort of like the difference between a lawyer and someone who has read a lot of books on law -- both may be able to instruct you on the basics of the law, but which one would you prefer represent you in court?
To get a better perspective on just how much this topic has been discussed within the community, you don't have to search for long: SharePoint MVP and consultant Marc Anderson tried to clarify the roles of developer and IT Pro, and consultant Jason Himmelstein followed up with further definition of what it means to be an IT Pro.
Kerri Abraham, a SharePoint administrator and self-proclaimed non-developer, followed up with an article centered on the idea that the definition of developer should be expanded to include designers and information architects. The point that Kerri was trying to make -- and which several members of the BOF audience tried to reaffirm -- is that those who build solutions should be called developers. Her logic was that whether these people built their solution without code, with SPDesigner, or with some other 3rd party platform, it is the output that defines the title. Kerri explains:
Traditional web development requires not only the mastery of writing custom code, but also the fundamental disciplines of analyzing business requirements, documenting change management strategy, and a focus on project management (just to name a few.) The real brilliance behind SharePoint is that suddenly the demands of learning code that kept most of us from traditional dev roles has been eliminated, allowing us to solve our own business problems.
Even so, Kerri recognized that software configuration management -- the management of code along its many branches and versions, which can become very complex very quickly -- and documentation may be hurt with the rise of the citizen developer.
Similar to Kerri's comments, one of the arguments made by the BOF audience members was that the definition of developer was expanding, and that with the right technologies to manage their activities, the lines are increasingly fuzzy, and will only continue down this path.
It's Not About the Technology
However, one audience member argued that this line of thinking was misguided, stating "People are trying to solve a people issue with technology, and no amount of technology will solve this. It's a cultural issue, not a technology issue." Her point was that the tools were irrelevant -- the real distinction had more to do with the scope of the roles, and the development culture of the organization. As with Rackley’s assertion, she stressed the importance of experience, repeatability and scalability in defining the skillset of a developer -- all of which are important irrespective of the technology used.
Development and engineering are distinct occupations -- defined roles that generally include years of schooling and training in one or more methodologies, and a background in structured design and development. On the other side of the coin are analysts and solution architects, many of whom may have limited formal education or training in the engineering discipline, but extensive real-world experience.
Some of these people are (not so lovingly) referred to as "hackers," but at the end of the day their focus is on building end user solutions -- getting things done. They may not approach the problem with the same level of rigor, using a known methodology (for the sake of transparency, documentation and quality assurance), but it does not diminish the value of what they provide.
The key to building out your SharePoint team is to understand the differences -- be specific in your job descriptions, and cut through the keywords and catch phrases of SharePoint practitioners to understand their true capabilities, education and experience.