Death of a SharePoint Developer
I have had to explain many times in the last year why I, a normal developer, am involved with Information Worker, which is (mostly) a SharePoint group? I am involved because I believe that the idea of a SharePoint Developer is a fast-dying one—and soon, people who call themselves SharePoint Developers will use it just as a way to justify higher consulting costs more than anything else.
I do not think this is because SharePoint usage is dying, rather the growth (maturity and adoption) of SharePoint is causing SharePoint developers to die off. This is not because SharePoint is so user-friendly that we no longer need custom code—because we still need custom code in SharePoint. The two reasons for my thinking stem from two questions: “What is SharePoint development really?” and, secondly, “What Microsoft is doing about SharePoint development?”
What is SharePoint development really? In SharePoint versions past (2007 and before), you would develop code for SharePoint using development concepts unique to SharePoint. Now that SharePoint has matured, development of the code for SharePoint involves concepts that are universal to development. Two examples highlight this maturity:
First, web parts, which are now the same as ASP.NET web parts; second, web services (and OData if you have SharePoint 2010). Both concepts are identical to those used by many other products from Microsoft and other companies. For example, if you understand how to get data from Twitter, with OData in SharePoint 2010, you’ll understand how to get data from SharePoint. Yes, you will have some SharePoint-specific bindings/APIs/code—but the concepts (the difficult part) remain the same.
I mentioned two questions, and the second concerns Microsoft’s strategy for SharePoint development—particularly their 2010 strategy (Visual Studio 2010 + SharePoint 2010). A SharePoint developer used to have to download special files, install them, fix issues, try installing again, fix more issues, and rely on special machines or virtual machines to run SharePoint. The actual process of just writing code for SharePoint meant becoming elite because you had to endure a ritual of fire before you could even start.
Microsoft has made SharePoint 2010 development simple—and, more importantly, easy to start with. They achieved this by making SharePoint run natively on Windows 7 and by including everything needed for development within Visual Studio 2010 from day one. Now, it’s as easy to start writing code for SharePoint as it is to make a WPF application!
What I’m trying to convey is that previously, a SharePoint developer had “paid their school fees” by learning so much that was specific to SharePoint development that they had earned a special title. Now that all those barriers have been removed, the title of SharePoint developer no longer applies—we are all just developers now!