SharePoint development is a fast growing industry, because it makes sense to many businesses to build custom solutions on top of a capable software product – especially one in which they have already invested resources. But SharePoint development is unique in many respects.

Firstly, there is the issue of professional experience. In my experience, there is a sense among many SharePoint developers that “the beast is too big” – in other words, that no matter how much training you put in and how many projects you have under your belt, it is impossible to fully master development on the SharePoint platform simply because the product itself is so big and so complex. That is not to say there are no SharePoint experts; far from it, in fact. But true expertise in SharePoint development requires an extremely deep understanding of all facets of the product, and many workaday developers—especially developers who run the SharePoint site as an administrator as well, which is typically in small and medium businesses—simply do not have the time to gain that depth of familiarity. I personally think that this feeling stems from two different origins:

  • SharePoint itself is so bulky that it is not very easy to develop against as a hobby or on your spare time. The product requires so much hardware to run that not all developers have the ability, even with virtualization, to build out a proper lab against which they can write applications that leverage all of the different features of SharePoint, especially the more advanced ones.
  • SharePoint development is unlike any other type of development, so skill transfer to other areas of need or client desire can be problematic. Because of the unique nature of the platform, SharePoint development requires proficiency in a standard managed-code language like C# or Visual Basic as well as a comfortable familiarity at the very least with web languages like ASP.NET. You also need to understand XML, HTML, CSS, and a variety of other frameworks, formats, and languages, and how it all fits together to create SharePoint solutions. This unique recipe sometimes requires writing code or assembling features in a SharePoint specific way that might not always be optimal in other scenarios where SharePoint was not part of the picture.

You might also have an identity crisis when considering SharePoint development. Do you want to be a solution developer? Do you want to be a web developer? How competent are you at web design? Do you want to write nitty gritty code? Do you want to drag and drop workflow components? If you answered “D – All of the Above,” then SharePoint development is for you. You configure a page layout, then write the solution code for it, then design the workflow, then test it, then deploy it, and so on, all the while dealing with access control issues and configuration problems on the platform as a whole. SharePoint development is certainly not a case of compile to an EXE, double click, and run. There is much more to it than that and the entire development cycle may not be something you wish to be a part of, nor might you have competency in every area required.

Debugging is also a concern, again because of the complexity of the platform. Performance problems are arguably the most encountered issue with custom SharePoint solutions, and yet the process of tracking down what components and interactions are causing a perceived slowdown can be difficult because of the number of moving parts involved in the SharePoint platform. There are so many logs (SQL Server logs, application logs, web server traffic logs), performance counters, indexing statistics and so on and often the problem disappears or rears its head at a different time that tracking down the problem via logs is difficult. In particular, the Unified Logging System , or ULS, in SharePoint is so verbose and yet so unclear that many times it is practically useless as an aid to debugging. In other cases, SharePoint developers encounter troubles debugging their solutions because the platform is so customizable that the consistency of the environment is a problem that cannot be planned well for in advance.

Finally, the process itself can be very complex. With SharePoint, you have to write code that builds the support structure that will let your actual solution code run: much like building the plumbing to build the house in which your new appliance will run. This can result in messy, late, and expensive projects, which are not the type of project most developers want to associate themselves with.

SharePoint development can certainly be done well, but it is a different and complicated form of programming that entails special considerations from developers themselves and from business owners.

James Matthews


Request a Demo

© 2006 - 2019. All Rights Reserved.