1 minute read
I’ve always been a lazy programmer and if you can believe it, I see this as a good thing. I never want to write anything more than once. (I’ve written an assembler-based keyboard handler for DOS. Do I need to do it again? As much fun as it was: no.) I also believe that the simplest way to solve a problem can often be the most elegant one.
With SharePoint, there are basically three “tiers” where you can do development: in the UI, in SharePoint Designer, and in Visual Studio. To me, you should think of the tiers in that order of preference, which goes from simplest to more complex. I ran across several posts today that I think back me up.
Thanks to David Whittle in Japan for the pointer to the Path to SharePoint blog. In it, Christophe shows us how to do some pretty amazing things by generating HTML in calculated columns, among other things. I might turn to SharePoint Designer for some of the things that he pulls off, but his approaches work just fine, depending on your environment. For instance, your governance rules may preclude you from using some of his techniques (You do have a well-documented governance model, right?), but that doesn’t make them bad approaches, just not the right approaches for you.
Christophe had a pointer to Joel Oleson’s blog where Joel talks about Webpart and Widget No Assembly Required Simplicity. Joel’s premise is that you can do a heck of a lot by using script-based widgets in SharePoint without actually writing *any* code. (Sure, you may need to configure a widget’s script through someone’s Web page UI and drop it into a CEWP, but that doesn’t count as writing code in my book.)
All in all some more strong arguments against needing a top notch .NET programmer to do very cool and useful things on top of the SharePoint platform. In these days of mashups and instant apps, don’t rule out these same approaches from being highly useful in a serious business application, either.