5

Not long ago I started an internship at a company that supplies SharePoint consultancy, hosting and development. While their consultancy seems to be pretty good and solid, I feel their development department lacks direction. The reason for this, most likely, is that they stopped outsourcing not too long ago.

One thing that I've frequently bumped my head into is the following:

My supervisor strongly insists that everything that can be done natively in SharePoint (somehow this includes editing xslt files in Designer) should be done in SharePoint. Even if this results in longer development time (at least when they make me write XSLT) and reduced usability.

Her main arguments for this are:

  • Better maintainability
  • Editing the functionality doesn't require programming knowledge

I feel the company is a little biassed and I am unable to get a decent discussion going. This is why I am looking for other places to get some responses on the subject (and not only on the arguments of my supervisor, but more on the subject in general).

Kind regards

SaphuA
  • 192
  • 8

4 Answers4

6

Editing the functionality in SharePoint may not require "programming knowledge", but in my experience most users need to be highly tech savvy to really understand the other ways to edit SharePoint, like SharePoint Designer and Dashboard Designer. I think if you can put functionality natively in SharePoint (like BCS), then that gives you CRUD screens for your existing data, workflow support, and more. With 2010 this is a real timesaver once everything is set up correctly, which can take months.

The incentive at a SharePoint consulting company is to bill as many hours as possible to increase profits. You get more billable hours by clients requesting work. Clients will request more work from a SharePoint company if most of their functionality is tied to SharePoint. SharePoint makes things easy for users with the tradeoff that development takes longer (yay! more billable hours for the company!). There is a happy medium to be met and the value of such work varies greatly from situation to situation, so the company not sitting down and having an honest discussion and blindly saying "put it in SharePoint!", is a red flag that it's less about the customer and more about the bottom line.

Ryan Hayes
  • 20,109
5

The reason you SHOULD develop in Visual Studio is that what you really should be generating is the little WSP solutions which can be deployed from

Dev --> Staging --> Production

You also have the packages solution, whether it be a Timer Job, List Template,Event Handler, BCS Model, Web Part etc which you can re-use throughout the environment.

With SharePoint Designer you're working live on the server and are not creating re-usable components.

Phill Duffy
  • 151
1

Even if you don't plan on writing custom event handlers, web pages, etc. you should consider using Visual Studio for the reasons Phil Duffy gives - it is much easier to manage code and, in the case of XML, easier to edit in Visual Studio than in SharePoint designer or NotePad for that matter.

Donkos
  • 11
1

Not everything can be done natively in SharePoint. Anyone who says that doesn't know SharePoint very well.

Having said that, there are a lot of things that can be done it's just a matter of what you want it to do. SharePoint is like a power users uber tool (think Access on the web) so it can be as simple as a TODO list to an entire Enterprise application infacing with external systems, and everything in between.

There is a lot that can be done out of the box so leverage it. For example, if you're building a solution which requires contacts use the contact list template as it's done for you (you might want to/need to add additional columns) and integrates to Outlook.

SharePoint has what I consider three levels of customization.

Level 1 is OOTB configuration. Just creating custom lists with custom columns and custom views can all be done in the browser with little knowledge of how SharePoint works yet yeild great impact.

Level 2 is when you crack open SharePoint designer and start building custom XLST views using DataView Web Parts, custom JavaScript/jQuery to either enhance the user experience or supplement missing features (like cascading drop downs, automatically filling in forms with pre-determined dynamic values, etc.)

Level 3 is full blown customization using .NET managed code. Custom SharePoint designer workflow actions, custom web parts, event handers. You name it, you're doing it here.

I like to balance out SharePoint life by living about 60% in level 1, 30% in level 2 and 10% in level 3.

YMMV.

Bil Simser
  • 330