Although I’m relatively new to the SharePoint Community (I just started blogging and actively tweeting earlier this year), I’m not new to SharePoint, or more specifically, SharePoint development. I’ve been developing on SharePoint for over 4 years now, first with MOSS 2007 and now with SharePoint Server 2010. So I feel like I’m qualified to add my two cents to the ongoing debates going on lately regarding what constitutes a SharePoint developer, and the different roles that are needed in SharePoint.
There have been several articles posted within the last year that touch upon these subjects. A couple that grabbed my attention are a recent article by Kerri Abraham, and a rebuttal by Mark Freeman. Kerri’s article contains links to a few other notable articles on the subject, so I’d highly recommend reading those as well for a complete background and context of the debate.
So What is a SharePoint Developer?
A few months ago I was having lunch with Kerri and she told me about an article that she was in the process of writing, in which she asserted that Laura Rogers and other power users who build solutions in SharePoint could be considered "developers", even if their changes only involved out-of-the-box usage of SharePoint or SharePoint Designer modifications. I must admit that I was taken a bit by surprise when she first threw this revelation at me. I mean, isn’t the term SharePoint Developer reserved for those of us who crack open Visual Studio and actually write code?
As Kerri was explaining her position, and after I pondered it more in the coming days, I realized that I was taking her use of the term "developer" too literally (this was even before I had read her article). You see by trade I am a developer, having started in Classic ASP and then moving on into ASP.Net and C#, followed by the transition into the world of SharePoint development.
When I develop a solution or a website, SharePoint or otherwise, there are certain processes that occur before I even start writing any code or begin implementation. At a high level - after requirements have been gathered I analyze them fully, looking at the complete picture, and then I design a solution. This could include anything from diagrams to formal design documents to proofs of concept to complete working prototypes, or any combination of those depending on the complexity of the need and the audience. And then I build it.
Since moving to SharePoint development, some of these steps are much easier, but the process is the same. I have created several SharePoint solutions that were done completely using out-of-the-box features. I have built some that are out-of-the-box and use a little SharePoint Designer. And of course, I have built many using Visual Studio. The only difference in my process for all these solutions was the implementation portion. Some involved writing code, others did not. The steps leading up to implementation were the same.
I think people who build solutions in SharePoint, those who don’t actually have the word developer in their title or function, really need to go through this same type of process. You need to think about the entire process flow when building a solution, even extremely simple ones. For example, we recently created a feedback site for users to submit feedback about our newly-released company Intranet built in SharePoint. Someone made the comment that it was just a simple SharePoint list, insinuating that it only literally took five minutes to build. But it did not. The list itself took about five minutes, but I also created a custom "add" form in SharePoint Designer so the users would only see the fields that they needed to fill out. I also changed the form action on the submit button to redirect to a custom Thank You page after the form is submitted (by default, SharePoint just takes you directly to the list after submittal). And of course I had to create that custom Thank You page that I redirected them to. I also added web parts to the Feedback home page that showed the user what the status was of their outstanding feedback requests (we set it up so users could only see what they submitted). This was an incredibly easy solution using the SharePoint UI and Designer, but I think it proves my point. It definitely didn’t take "just five minutes" to implement, and it required analysis of the complete user process flow up front to ensure the best user experience.
I think management or people not that familiar with SharePoint often make the incorrect assumption that if something can be done out-of-the-box, that it is always very quick and easy to implement. Not so! I’m currently trying to make this very point at my company (not sure I’m having a lot of success right now on that front). I think an article on this subject is forthcoming!
The Other Side of the Debate
Being the diplomat that I am, I also agree with Mark Freeman when he says that we need a true definition of the different SharePoint roles and why it’s important to do so. Wait… what? How can that be? How can I agree with both Kerri and Mark when they seem to be in total disagreement with each other?
I think it’s definitely important to understand all the roles that are required for maintaining and leveraging SharePoint for business solutions. Employers need to list specifically what SharePoint skills they are looking for, and not merely a title, because titles are so vague. It’s precisely because there are so many different aspects of SharePoint and skill sets necessary that it’s all the more imperative that specific skills be listed on job postings.
And herein lies the problem: unless a company already has a SharePoint expert on staff who understands all the different aspects of SharePoint and the roles required to implement/support it, most companies aren’t going to have a clue as to what they need. That’s why there needs to be a comprehensive list that everyone agrees on, that explicitly lists out the roles and responsibilities. Will there be crossover? Likely. A commenter to Mark’s article listed out her definition of the necessary roles needed, including Application Developer, SharePoint Developer, SharePoint Designer, and Site Solution Creator; and then she lists the specific skills that each role entails. For the most part I think it’s an accurate assessment, but a lot of companies aren’t going to have that many different SharePoint people on staff, so one or two people could likely be performing any or all of those roles. I actually fulfill all four of those roles at my company, and that is what our definition of a SharePoint Developer tends to be, perhaps incorrectly so. We may reach the point someday where we have power users who become Site Solution Creators, and we may have non-developers who become proficient with Designer and can fill that role. At the current time we just aren’t there yet.
What’s In a Name?
In her article Kerri explicitly points out, more than once in fact, that she is not advocating that Laura or any other power user who creates solutions in SharePoint put the title SharePoint Developer on their resume. What she is saying is that anyone who creates solutions to solve a business need is developing the platform.
There’s that word again, develop. Ultimately I think the real issue here is one of semantics. A power user who labels someone that creates out-of-the-box solutions in SharePoint a developer is likely to rub some "true" developers the wrong way (myself NOT being one of them; personally I don’t care what you call yourself, it won’t offend me). Perhaps we should call them Solution Builders (or Site Solution Creators as the aforementioned commenter suggested). If you create an out-of-the-box solution in SharePoint, one that solves a business need, aren’t you building a solution, even if said solution did not involve writing any code? The answer in my opinion is a resounding YES!
I do think we need to qualify, however, exactly what constitutes solution building in SharePoint. I’m not talking about someone who simply creates a team site and uses all the out-of-the-box lists and libraries to collaborate with their team. Or even someone who creates a custom list to track something. I’m referring to those who create end-to-end solutions; perhaps it utilizes content types, workflows, calculated columns, the data view web part, page layouts, or custom master pages.
At my company we subscribe to the mantra of first try to build it out-of-the-box; if that doesn’t work then try it using SharePoint Designer, and then Visual Studio. In fact, our governance plan states exactly that under the Customizations section. Yes, we consider out-of-the-box solutions to be customizations, along with SharePoint Designer and Visual Studio solutions. Our plan clearly states that developers must first attempt to design the solution using out-of-the-box techniques. If that isn’t sufficient or becomes too timely/costly, try designing it using SharePoint Designer. If, and only if, the customizations required are beyond what the previous two methods can handle, only then do we get to crack open Visual Studio.
Some developers have a hard time with this concept and want to jump directly to writing everything in Visual Studio. The issue I have with this is that a lot of what developers write could have been done more quickly and easily either with Designer or through the SharePoint UI. The key is knowing exactly WHAT can be accomplished out-of-the-box. That is why I strongly believe that all SharePoint developers (and when I say developers, I mean the ones who actually write Visual Studio code) first need to be power users of SharePoint so that they will have this understanding. This will likely be a topic for another post as well.
Whatever label you want to attach to it, the SharePoint community has some fabulous power users out there who are utilizing SharePoint to its fullest to create solutions for their users. I’m constantly amazed at how creative these power users have become in figuring this stuff out. I have a lot to learn in this area. For me it would probably be easier to do something in Visual Studio, just because that’s my mindset and where my comfort zone lies. But for those who don’t have access to Visual Studio or even Designer, they have truly figured out how to maximize the SharePoint framework and create some brilliant solutions. Because in the end, that’s what it’s all about anyway: creating solutions for your users that solve a business need and provide value.
This article was originally posted on Wendy’s blog SharePointWendy.