Introducing Office Developer Patterns and Practices

Ever since SharePoint Portal Server 2001 was released at the start of the millennium, developers and businesses have tried all types of approaches to customize and bend SharePoint, one way or another.

SharePoint, after a default installation (which in itself is a discussion for a whole other book!), is referred to as an Out-of-Box (OOB) SharePoint. In its history of 15 years of releases for on-premises versions, and more than 5 years of updates with SharePoint Online, developers have always found ways to modify, change, or even remove built-in SharePoint functionality. This could be because of business requirements, usability reasons, or simply that a developer feels that he or she can implement a better implementation of a SharePoint feature.

This has resulted in numerous issues and headaches for both Microsoft, ISVs, Microsoft partner companies trying to make a living providing SharePoint-based solutions, businesses and their IT departments trying to support SharePoint, and end users trying to figure out how to do their work within SharePoint. There were, and still are, dozens of ways to do a simple change, such as changing the overall look and feel of a given SharePoint site, and while some of those are strictly not recommended, others are more or less either supported or at least not forbidden.

Developers accustomed to implementing SharePoint-based solutions might not often be aware or any sorts of best practices or common guidelines on how specific changes should be done. With SharePoint Online, the problem is two-fold: on one hand, developers might not have an API or an approach to change a facet of a given SharePoint feature. On the other hand, developers are not always sure how to do something, even if there's an API or an approach. Chances are that for any type of change a quick Google search will reveal at least five similar approaches. Some of those approaches might not work anymore, some might not be recommended, and some are poorly documented.