Why SharePoint Development Tools are Bad for You!

I got this email comment from a reader of USP Journal (reposted with permission of the reader):

Hello and thank you for creating this great journal! I just finished “Professional SharePoint Development” and I recently implemented a project where these methods could be useful (they’ve already started changing themes and things just after release to production).

I know you like the VS2008 dev tools for SharePoint better but I think it would be appropriate to put a bit more work into adapting the article to VS2010. I wasn’t real familiar with the new toolset either but my company requires that I use the “latest and greatest” stuff so I found myself struggling to complete the steps of the project in VS2010.

I’m very determined to figure out the new tools and how they contrast with WSP Builder stuff and was eventually able to find equivalent steps in VS2010, however, others might be put off by your neglect of the tools that Microsoft is clearly pushing. Are the VS2010 tools used in VS2012 and SP2013 as well?

I get this question a lot, and I’ve written about my sentiment previously, but I’d like to once more bring the issue up because it is important and affects a lot of SharePoint developers.

Don’t Be a Tool!

Tools in any trade are there to make a known task easier. In other words, you need to learn and master the underlying task before you start using tools to speed up or ease the task. If you don’t master the underlying task first, you become just a tool user, not a task master. You know how to use the tool but not how to perform the task because you let the tool do the task for you.

Your situation is a perfect example of why understanding the underlying tasks are vital. You’ve just found a great method to build maintainable solutions, but you can’t use them because you understand many tasks from a tool perspective only. When I explain these techniques to master SharePoint developers, the quickly grasp the concept and are able to start utilizing them almost immediately, and we don’t even mention what tools we use.

In fact, I’ll go as far as saying that tools make idiots and that a lot of the crap we hear today about how one should avoid using custom code in SharePoint is because of idiots that have learned development using the brain dead out-of-the-box Visual Studio tools for development. Those tools create those idiots, and now Microsoft is paying the price by having a great development platform they have to recommend people don’t use. You don’t create great developers by giving them a point-and-click adventure game, and that’s about the most positive thing I can say about the Microsoft tools for SP development.

During my Beginning SharePoint Development courses at USPJA, the students spent the first three of six weeks without using any tools at all. The only tools allowed were Notepad and Makecab (I think I later allowed them to use VS just for editing but not for building) and they had to build their first taxonomy solutions using Notepad and Makecab only. Then, and only after proving that they knew the tasks like the backs of their hands, were they allowed to use any tool they liked, WSPBuilder, VSeWSS, STSDev, and I didn’t really care which one they chose because they were able to solve their problems with any of those tools.

I strongly believe that tools are completely irrelevant to a SharePoint professional. I have used the Professional SharePoint Development techniques on every platform (2007, 2010, and 2013, both WSS/Foundation and Server) and using virtually every VS tool and version there is, including the god-awful Microsoft ones (aka the ‘latest and greatest’). I just got contracted for a job where I’m required to use VS2012 against SP2010 and that’s completely irrelevant to my ability to perform the tasks. It does affect my efficiency to some extent because I have thousands of hours of practice using WSPBuilder and have only done a few major projects using the Microsoft tools.

Many clients with whom I work are initially very concerned with what tools I should use to do my job. Usually this is because they already have someone who knows how to do a task using a specific tool only, and sadly, this usually means that Microsoft thing. If they need to maintain your solution and they only know one tool, well, then you need to use the same tool as they.

That makes about as much sense as telling your doctor what pills or medicines she should use to treat you, or your carpenter what brand of hammer he needs to use to fix your leaky roof, based on the fact that you want someone else to continue treating you later, and they only know how to work with Tylenol or that your cousin needs to maintain the roof and he only has a Craftsman 16 oz. curved claw hammer.

After a few weeks, though, most clients realize that the tools are irrelevant to anyone but novices on wrong paths and let me focus on doing my job using the tools that make sense for the task.

So yes, the techniques taught in Pro SP Development work with any tool. I show examples using WSPBuilder because I’ve found I’m 2-3 times more productive with that as opposed to the Microsoft thing. If someone can’t understand the techniques based on not knowing the tools I used, then that’s a problem to solve rather than having to create two (or five) versions of the same document to show examples to people who only learn the tools, not the tasks.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

11 thoughts on “Why SharePoint Development Tools are Bad for You!”

  1. I totally believe this view to be lacking somewhat.

    I know developers who know code backwards, but are dyslexic and cannot develop without syntax highlighting in a certain colour scheme.

    I know developers who learnt with the tools you say and actually have lessons drilled into them about code formatting and structure that makes your code easier for a compiler to manager.

    I know developers who have learnt with notepad and write the most awful code you have ever laid your eyes on…

    The problems with writing in languages like C#, CAML etc. without a tool is that while your code may work fine, it can more easily have mistakes and be far from optimal. The first tool that fixes this is syntax highlighting, the second is hinting, the third is helper functions like go to definition, the fourth is reflection and so on..

    The worst case is JavaScript, I challenge you to write a whole application that is written optimally for a compiler without a tool to help you with the very VERY strict syntax of use strict.

    Tools are there to aid efficiency and used correctly to aid learning, you can look at what the tools are actually doing for you and learn from that level as well. It is the misuse of tools that causes these problems, not the use of tools.

    1. I think you’re grossly misunderstanding the point of this article. Tools are great, but only once you master the underlying techniques. If you don’t, you learn the tool, not the technique and you’ll become a tool that knows the tool only. If the tool changes or is unavailable, you scratch your head and can do squat.

      Learn the language, then use tools to speed up your development. Do it the other way and you’ll have a hell of a time if the tool are insufficient.


      1. What I am getting at is that tools can be used to speed up the learning process, and better understanding the structure of the languages in question.

        You can use a tool to learn the techniques to their fullest, and with every iteration of the tool you learn more.

        I do not know of a developer at my level who hasn’t learnt this way and we are all capable of writing in notepad or in visual studio.

        My response in short is, I have seen those taught with both ideologies and if taught correctly, tool driven learning is faster and much more rounded and they become better developers.

  2. I completely agree with the sentiment that you need to understand the underlying technology FIRST .. before you learn the tool (which is probably my #1 criticism of how SPD is used)

    This is akin to someone who can use a calculator but has no understanding of maths .. they can push the buttons in the right order but when it goes wrong they are left clueless.

    But the development tools themselves are not the problem, the problem is a lack of quality and authority in a lot of development shops who are working with SharePoint.

    In my opinion development tools (used in the right context) can be awesome .. they allow you to code quicker, with more confidence, and in some cases can allow you to do things that normally would be a complete pain in the backside (CKS:Dev .. I’m looking at your gorgeous!)

    Personally I think if you are using CAML you should be able to read and understand the underlying XML in notepad … but I’d say the same about CSS / HTML / ASP.Net / SQL and CSS ..

    Having said that, if the whole world followed that mentality then cars would still be built by hand in small factories and would all cost a small fortune .. computers probably wouldn’t even exist (how many people working in a factory actually understand what the tools they are using DO .. and how they work ..)

    The sentiment at it’s base level works, but don’t take it too far 😉

    1. Martin,

      I use a mouse and keyboard every day. Those are tools that save me from having to encode the signals to move pointers around and put characters on my screen. I have no idea how those tools work. I use them solely to get things done.

      However, I am not a mouse or keyboard designer. I am a SharePoint developer. The tools I use to input whatever I need to get SharePoint solutions built are irrelevant. I can build on a smart phone without neither mouse nor keyboard. These aren’t the tools of my trade.

      I don’t think that the people who build cars don’t know how a car works. For example, a car painter needs to understand not how to point a paint gun at the bonnet, but how the paint connects and stays on the surface, how much to apply to each part, how to harden and polish the paint, and so on. Yes, they use tools, but they understand the underlying techniques.

      A main difference here is that mass-producing code is vastly different from mass-producing cars. You don’t need to rewrite the same code for every customer that buys your solution. If you build solutions for the mass market, knowing the underlying tasks is that much important.

      On the other hand, most SharePoint development is unique to a situation and scenario. There are commonalities between the solutions, but each company has unique challenges that needs unique solutions. Again, because tools do not teach you how to master the underlying tasks, learning using tools means you are blank when the needs of the solutions go beyond what the tool was designed to deliver.

      Consider also that hand-built cars are generally considered to be of higher quality than machine stamped vehicles. Look at Aston Martin. They are built by hand in a small factory and cost a small fortune, but boy, I’d have one over a Fiat Panda any



  3. Hi Bjørn,

    Great article and very curious learning technique 🙂 Well, I assume limiting them to Notepad+Makecab is a bit too much, but the idea itself really makes sense, especially when dealing with SharePoint and its whims.

    Because you may struggle with those SharePoint “bugs” for hours and days and years, and swear it all along, and be unhappy and hate it if you don’t understand what is its history and how is it built and what actually happens inside there.

    Yet if you know how the SharePoint works internally, you will most likely naturally avoid all those obstacles without even thinking about that.

    Thanks for the article!

  4. Well said that man, when I started with 2007 all I had was manifest files makecab and ddf. Because I know that stuff I can go poke around in the xml and figure out what’s wrong. Without that knowledge I might waste hours trying to figure out what stupid thing has gone wrong this time.

    But maybe I’m only agreeing because Im sadistic and want everyone else to feel the pain. 🙂

  5. Couldn’t agree more. I started SharePoint development back in 2001 and there were no tools. There wouldn’t be for another couple years. Then the tools that were available from MS, were lacking, and often times wrote incorrect CAML. Even today with the VS 2012, it still writes modules wrong. I’ve worked with WSP Builder, vs 2010 & VS 2012. I like using the tools, but I’d be lost if I didn’t understand the technology first. Case in point, when I have to troubleshoot, I can spot errors much quicker than my coworkers, who only understand the tools. They don’t know where to start looking when things are broken.

    As a side note, it’s good to see you back Mr. Furuknap 🙂 Really enjoyed your SPInvoice journal.

  6. I’m a fan of WSPBuilder…even rebuilt their solution so it would work with SP2013. However, like the author here, I feel the fundamentals must come first. At one time, I built my own wsp’s, painstakingly writing the manifests by hand. I absolutely hate the Microsoft Visual Studio SharePoint templates–I’ll create my own folder structure, thank you very much.

  7. Very well said…while mastering the tools might get you to some place as far as development is concerned, mastering the underlying concepts about the actual development will give you a strong backbone in the industry.

Leave a Reply

Your email address will not be published.