Developer awareness and the bad reputation of ‘SharePoint Designer’ – A post to all developers.

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!

Advertisements

8 Responses

  1. good article!
    I have done several SharePoint 2007 projects now and have never met a developer who used SPDesigner…
    You are right that custom development for SharePoint is tricky and I have found that many assumptions turned out really bad.
    There is a guy at the company I work for who is advocating the use of SPD (he is an analist) and I think I will join him. At least to stimulate the devs to investigate the possibilities.

  2. Hey Emile,

    As you know, this article fits me like a glove. I’ve come to really like SPD, and have even come to like NOT writing any code (ok, some…).
    SharePoint is a wonderful product, if used the way it should be (i.e. not in the way of building an ASP.NET app and then hacking it in SP… ).
    Thanx!!

  3. Oh hell yeah!!!!!

    I totally agree with you! Sharepoint Designer 2007 is very sexy! I am totally in love with it! No more custom development for every little thing (except WF activities, site creation, etc.)! It is fast and easy! I just love it!

    ^-^

  4. Nice article, I’m not sure SharePoint Designer is “very sexy” as the last comment assesed, 🙂 but the latest version of SharePoint designer is a windows explorer,an expressions Studio, a workflow wizard, a black belt nija, and much more. I used the first version of SharePoint designer in 1997 and it left deep scars. The latest version is helping to heal those wounds.

  5. You say “I’ve always been an developer, and still am!”, but this doesn’t sound like development to me. In fact, it doesn’t sound like a satisfying experience. I’d be concerned that I’d lose my edge… like I’m demoting myself to a power user. It sounds more like assembly and a lot of pointing and clicking.

    Maybe it’s just outside my comfort zone as you say, but I’m concerned that I won’t like the experience. What is it about the the SharePoint Designer experience that helps you like it (as a developer)?

  6. @HB: Well, actually i am not woried (anymore) that im losing my edge. Since I still do a lot of custom application development on top of SharePoint itself. I am just using SharePoint designer as a tool for my SharePoint factoring process.

    Actually, since i’ve been using SharePoint Designer i’ve become even more of an developer since i’ve been building an huge toolset to export functionality from sharepoint designer to features and solution packages (thus allowing modifications from Sharepoint designer to be compatible in traditional WSP packaging)

    But since i’ve been using SharePoint designer, i am far more agile in a way that i can create rapid prototypes and workflows and get feedback from the customer early. Also when something doesn’t come out of the box i create functionality that i can re-use in SharePoint designer.

    The things i like best in SPD:

    – DataFormWebPart customization (XSLT)
    – CSS, masterpage, styles en layoutpages customizations
    – Workflow functionality

    But your comment does certainly ring a bell, and i think that this also i one of the major things with developers, they feel sharepoint designer is degrading yourself to a simple click-dummy. However, since i am able to give feedback and prototypes to the customer early in the process. and give better indications on what is custom and what’s not, i see the clear advantage.

    Also, i still create custom webparts, and custom workflow activities and so on, i just make sure that i can use them from withing SharePoint designer aswell. If you mail me, i can give you more information on the proces.

  7. Absolutely Correct!

    SPD has amazing power, and I would actually say that 95% of the work needed for any solution can be done with out of the box SharePoint webparts or SharePoint Designer.

    It’s the special scenarios that you want to build code for. I am always amazed in working with different companies how little they look at the tools and power available to them. I can’t count the number of times I have seen developers build a webpart that already exists in SharePoint.

    I have even done it once. Mind you I only did it once, then read and learned everything I could about SharePoint designer and the built in SharePoint components so I wouldn’t duplicate my efforts again.

    I hope everyone else sees the value you do in SharePoint Designer,
    Richard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: