Agile SharePoint Development

SharePoint is a strange framework. It provides you with an incredible amount of functionality. You can customize it in many ways, by configuration and by code. Power users love it. Yet it feels like computer science stone age to developers. When browsing the interfaces and decompiling the classes, you could constantly post to Just think about the user data storage table. Accordingly many SharePoint development projects uses processes from the computer science stone age, somewhere between the Waterfall model and Cowboy coding. This works fine for smaller projects, but it introduces a large cost for somewhat more complex undertakings. The power SharePoint gives to its users is a rich source of ideas, and with ideas come change requests. This is where agile development processes come into play. Embrace change. Users often update their mental model of their business processes, with each implementation you provide. Follow their updates, and they will be happier.

Change is also a risk. You might break something. Or worse, you might break something without noticing it. This is what the following article series is all about: Reducing the risk of change in SharePoint projects.

  1. Updating Data Structures
    Your lists will have to change. Your content types will have to change. This is about how to deal with mutable data structures without losing user data.
  2. Isolating Test Data
    If you run automatic tests, be sure to do so in a reproducible way. This posting shows you how to isolate the test data, to avoid interfering with future test runs.
  3. Isolating Test Code
    SharePoint has a special relation to the Global Assembly Cache. Get to know the implications, and learn to avoid the GAC.
  4. Dependencies
    Testing against resources such as the SharePoint Log makes it hard to verify the result. You might even introduce conflicts. Learn how to apply dependency injection to SharePoint to improve testability.
  5. Refactoring
    Tool support for refactoring C# is great. For CAML, it isn’t. Learn how to use POCOs and LINQ in a clean way, avoiding LINQ-to-SharePoint.

SharePoint: Missing NoSQL Backend

If you have ever programmed for SharePoint, you probably had a look at the content database, just out of curiosity. And if you did so, you probably closed it and never looked at it again, because you can’t stand the outstanding abuse of SQL as a data store:


Yes, the columns are named “nvarchar1”, “ntext1” and so on. If you ever wondered why SharePoint has some strange limits on the number of variables on a list, now you know why. There are just so many columns of the respective primitive type in the user data table.

SharePoint tries to map non-relational data to SQL. On the one hand, it supports multiple Content Types per list, so each item can have a different set of attributes. On the other hand, it does not expose transactions, joins, or any other feature SQL developers use on a daily basis. It looks like they just had to find some kind of data storage which is accessible over the network and can be shared by multiple instances of SharePoint. In this regard, SQL Server seems like a reasonable choice, at least when your only alternative in the Microsoft product stack is SMB/CIFS.

Nowadays it looks to me as a great opportunity to use a document database as backend, such as MongoDB, RavenDB or CouchDB. If SharePoint List Items would correspond to documents, there was no need for mapping attributes to enumerated columns, they could be stored as is. SharePoint exposes nothing which could not be done on any of these NoSQL databases. I know that it is unreasonable to expect Microsoft to support a NoSQL backend in an upcoming version of SharePoint. But I would like to spread the word to show SharePoint developers that there is a sane world out there. And if they are ever in the position to design a system, they should evaluate all possible backends to find one which matched the concepts of the system, not just one which can be forced to do the job.