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

  • As a note, sometimes maintainability is about more than knowledge. Editing XML files and programming may be close enough that the same tech-savvy person could do both, but those XSLT files are more accessible and quicker to modify. They're more visible, which can mean more maintainable in some sense. Mar 8, 2011 at 17:06
  • 1
    Well, the good news is that you're not alone. Every SharePoint consultancy group I've dealt with is pretty lacking in the development department. Mar 24, 2011 at 20:03

4 Answers 4


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.

  • In the limited bit of sharepoint work I've done, my opinion has been that most companies probably don't need Sharepoint or get the benefits that they could from it. It's a very powerful, bloated tool, and editing it can range from in-site customizations through edit menus to sharepoint designer page builds to VS web part programming. But SP is hot, in depend, and complex enough to require consulting knowledge, if not programmer knowledge, so I agree with Ryan that some shops are definitely pushing it hard because it means more client work for them. Mar 8, 2011 at 17:03

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.

  • 1
    I had a developer tell me SP designer could make re-usable components. She then told me to write every step down that I did in designer and use that to reproduce things. I told her she was nuts. Mar 24, 2011 at 23:02

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.



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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.