Considering writing some custom code for your SharePoint implementation? Think again.
SharePoint Can Do Many Things
SharePoint 2010 is a product of considerable size. It’s feature set is split into six separate areas by Microsoft. These areas cover social networking, communities and collaboration, search, business intelligence and much much more. In short SharePoint is a behemoth of a tool.
SharePoint is at heart an enterprise content management system, suitable for a wide range of uses, though it isn’t suitable for all projects and implementations. Many clients come to me expecting it to replace a custom web application. They look to InfoPath forms and list based storage as a way of replacing a SQL server data store and custom screen designs -- this is not what SharePoint is designed for. But for Intranet, Extranet or website applications, SharePoint can be pushed and molded into a variety of uses.
Supporting the SharePoint ecosystem are a wide range of third party companies and service providers. Some of these companies offer just basic single web parts; others like Nintex offer significant upgrades to built in functionality. But generally speaking your clients won’t be facing totally unique problems each time, and someone else may well have solved the issues already and packaged it up nicely for reuse.
Writing Custom Code is a Mistake
This combination of core product and supporting tools offers clients a very capable CMS platform. So what do many SharePoint vendors go and do during the implementation phase? They litter their solutions with custom code. Custom code to change branding, tweak controls or extend functionality. Custom code to solve basic problems, or get around some of SharePoint's nuances. This is a tragic waste of time and money, for 3 very clear reasons.
1. There's Plenty of Functionality OTB
SharePoint offers so much functionality out of the box that time and time again people fail to make full use of what is on offer. It often appears easier to write some custom code to solve a problem, rather than investing the time to learn the ins and outs of the product. SharePoint gives users a whole box of building blocks to play with. But it does take someone with a real knowledge and understanding of the product to know how to use these blocks effectively.
Paying for features, and then not using them is never a wise use of IT spend. Instead clients and vendors should invest in training to enable staff to be able to make full use of the available feature set.
2. Writing Custom Code is Not Easy
Sure, lots of Microsoft partners have very capable development teams. And there is huge support for the .NET development environment from both Microsoft and the online community. But writing new code is inherently difficult. It needs designing, coding up, testing, testing again and then user testing.
Not only do you need to write the code, but you will then be expected to support and maintain it. Documentation will need to be written, and handovers carried out as staff turn over. Why go to this bother when you could solve 75% of a problem using out of the box features? Features that have been coded using another developer's blood and tears, and are supported by enterprise agreements and support plans.
3. Your Code Has a Shelf Life
Now this does apply to third party applications as well, but any code you write may well be limited to the current version of SharePoint. Your investment in custom code will disappear when SharePoint 2012 hits the shelves. Your clients are likely to expect an ‘upgrade’ of your code as well as their SharePoint installation. You did cost that into the project didn’t you?
Make Sure Custom Code is Necessary
So next time you fire up Visual Studio on your SharePoint project think twice. Are you sure you can’t solve the problem another way? Are you sure that MySites, the content query web part, or views can’t help? Because if they can, I guarantee it will benefit both you and your client in the long run.