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!