Sample code acceptance checklist for IT organizations


Recently, there has been the Sample code acceptance checklist for IT organizations published at Microsoft TechNet. This checklist is meant to help IT organizations evaluate custom SharePoint solutions before they are deployed in the production environments.

Because many SharePoint solutions are really complex, such checklist is definitely something you must have implemented in your organizations if you have an IT department and want to keep track of what has to be supported. I’m a developer myself, yet occasionally I talk with my colleagues and customers about various challenges of managing the life cycle of SharePoint solutions. Looking at the checklist I have found a few items I’ve been either missing or not totally agreeing with.

Structured and repeatable deployment

By now we all should know how important the ability to deploy a SharePoint solution in a structured and repeatable manner is. Unfortunately I’m still regularly talking to SharePoint developers and customers who both underestimate that concept. SharePoint 2007 ships with a framework for deploying the assets yet it lacks a mechanism for deploying the configuration. Because of it, way too often things are being either configured on-the-fly in the production environment or databases backups from the development environment are being restored to the production environment to deploy the configuration. I cannot stress enough how bad this for manageability of SharePoint solutions and how prone to errors it is.

The code acceptance checklist totally skips the concept of the structured and repeatable deployment of SharePoint solutions. It mentions the solutions only in relation to deploying Web Parts but that’s all.

Versioning

Initial deployment of a SharePoint solution is just the beginning of its life-cycle. The more the solution will get adopted by the customer organization, the more new requirements and changes will be requested. Providing these changes in a manageable way requires planning. It is not only crucial that all dependencies are known but it also demands a concept of how to version the changes and provision them in a best manageable way.

This subject is missing in the Sample code acceptance checklist.

Implementing server-side data validation only

According to the checklist a SharePoint solution shouldn’t rely on the client-side data validation and implement server-side mechanism instead. That check item doesn’t say that you must not use client-side input validation, but in my opinion it discourages it.

In the last few years the technologies for web development have evolved a lot. JavaScript for instance got even more powerful and the way it’s supported by various web browsers is continuously improving. Providing immediate feedback right after data input improves the user experience and saves time! Just look around you: client-side input validation is everywhere no matter if you’re using one of those fancy Web 2.0 applications or create a new Google account. Both WSS and MOSS team know it and they have implemented it in SharePoint. Just try to create a new Publishing Page with for example a # (hash) in the URL name to see what I’m talking about. While that entry form is pretty simple correcting mistakes in complex form without client-side feedback might get really annoying.

So why we are supposed not to benefit of that technology? While I don’t understand the choice myself, I agree with a part of the sentence: you should never rely on the client-side validation only as it can be simply turned off. Instead support it with server-side validation which will provide you sufficient control of the user input.

Character encoding is set preferably to ISO-8859-1

Since quite a few years we see more and more of UTF-8: it’s in XP, in Vista and probably also in MacOS and *nix as well. It took developers around the world quite some time to figure out how to deal with the problem of various encoding and now we are supposed to take a step back in the evolution and use the ISO standard? The code acceptance checklist puts this item in the security section. I don’t believe though that it’s a SharePoint specific concern. I’d rather expect it either to have something to do with the .NET framework, IIS or Windows itself.

Unicode has been designed to solve many multilingual problems and provide a standard way of encoding non-ASCII chars. I don’t think we should go back to where we were 20 years ago.

Summary

The Sample code acceptance checklist for IT organizations is definitely a great piece work and a step towards better manageability of SharePoint solutions. We aren’t there yet but the first step has been set. I believe that the checklist has the potential to become very useful after it has been reviewed, improved and extend with explanation of at least some of the guidelines.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007, WSS 3.0

Others found also helpful: