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 http://thedailywtf.com/. 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.