Developer awareness and the bad reputation of SharePoint Designer
*This post ferociously tries to persuade standard .NET developers by offering them candy to give SharePoint a designer a chance, cause it is indeed a black-belt ninja. And you want it, you know you do.
As a contractor, I often run into the same thing over and over again. For instance, when an client need to get things done in SharePoint (and I’m not available), they often acquire an traditional ASP.NET developer. However, this is what usually happens. Because traditional developers are technical experts they often try to solve the problem using their comfort zone and start hacking in Visual Studio. Most developers haven’t even considered using SharePoint Designer or InfoPath because it’s ‘a WYSIWYG tool, meant for analysts that are wannabe developers, and just looks like front-page’ . Well, don’t blame them, front-page wasn’t that good and Visual Studio has been superior in many ways. And heck, my first SharePoint experience was indeed in combination with Visual Studio. (I’ve always been an developer, and still am!) But don’t be fooled here guys! It’s time for a change..!
At least 70% of the solutions that customers want in SharePoint can be done using SharePoint designer, without typing any or little code. It provides work-flows, custom forms, designing pages, roll-up functionality and loads more. If you are unsure of its capabilities, check out: WSS 3.0 40 Application templates. Its a nice showcase on what SPD can do.
Therefore, the first thing I do is inform the new developer to learn that custom development in SharePoint is only meant as a last resort, should not be taken lightly, and should be aimed at developing specific bits of reusable functionality. Such as WF activities, site creation logic or other things that don’t come out of the box. I say this, because as soon as coding place, the project gets a lot harder to manage.
This is usually because the developer has an incredible extensive object model to take in account with all its features such as security, deployment and performance. Also actual development process is slower in general because proper SharePoint development consists somewhat out of an more complicated development cycle: Build, sign, build WSP, addsolution, deploysolution, find bug, attach debugger, etc etc. And then there is the feature framework to take in account. Of course many things can be automated but it is still somewhat slower than traditional ASP.NET development. Also, the development tools available for SharePoint are still a bit lacking. Another pitfall with SharePoint development is that a lot is often assumed to work in a particular way. Furthermore, the custom developed solution needs to be tested, and maintained trough every version iteration of SharePoint. This doesn’t mean that SharePoint development is a no-go, or a bad thing to do, its just something that needs to be considered thoroughly, planned and carefully managed. Also, one needs to be 100% sure that their isn’t an alternative available out of the box. SharePoint development should never be done ad-hoc or sold that way by managers to customers. I personally recommend every developer to try to solve the problem using SharePoint designer first, and if that isn’t possible see whether one can extend SharePoint designer’s functionality by for instance developing custom workflow activities or web-parts that can be reused in SPD.
However, SharePoint designer is not the holy grail. And at some points you need to have a hybrid solution, thus half of you project will be done using SharePoint designer, and the other half will be solved using custom development. It is not a hard line, but just make sure you get the highest efficiency using both products.
All traditional developers should become aware of this, should be thinking less about the technical part, and more about the functional aspect of the solution. SharePoint is an product intended to be used by businesses for creating solutions to gain more ease and speed by using out of the box software. Make sure you know every bit of SharePoint before you start up that Visual Studio and hack away!