20 12 2011
5 Common Mistakes Made By New SharePoint Developers
After some time now supporting many others in the use and development of Microsoft SharePoint as a platform, I’ve come to notice some common traits of people who are new to developing solutions. I’ve decided to list the 5 most here, and I hope that these cover both those who are currently developers getting started with SharePoint, and those who’ve used SharePoint a little bit and have been graced with the task of developing a solution in the platform, wearing the ‘developer’ hat for the very first time.
Not Understanding The Capabilities of the Platform
Let’s face it. SharePoint is big. Massive. Enormous. Possibly bloated, even. It can do one hell of a lot of things, and one of the things that trips up a developer when asked to do something in SharePoint, is that they might no realise that SharePoint already does part of what they need. So they end up reinventing the wheel. Sometimes reinventing the wheel means you end up with a bigger wheel, but also you will have to look after and support that wheel for when it breaks, and you may also have wasted a load of time making that bigger wheel. Sometimes though, the wheel that comes with SharePoint might be square shaped, and thus not do what is required, forcing one to reinvent it. Always find out if you can if SharePoint can already do something that you need it to, before embarking on development effort to build something.
Not Making Full Use Of The Tools
The web UI can help you do a fair bit, and solve quite a fair amount of common, simple business requirements. Then there’s SharePoint Designer, which gives you a little more power. Finally, there’s the all-powerful Visual Studio. That’s a wide range of capability, though people use what they’re comfortable with. New developers to SharePoint will probably always hit Visual Studio first, blowing in with an over-the-top solution to a dead simple requirement such as a simple list with a couple of views, and the substantial learning curve that comes with this simple requirement that could be satisfied simply in one of the other tools. Or experienced SharePoint folks might go no further than SharePoint Designer and end up with extremely complex, over the top solutions to satisfy something that could solved really easily with a coded solution in Visual Studio, should they ever have decided to brave it. Give all the tools consideration when deciding how to implement a solution in your environment.
Not Understanding Best Practices
There’s more than a dozen ways to skin a cat and there’s even more ways to accomplish tasks and satisfy requirements in SharePoint. Not all are the best idea. There’s performance, security, scalability, portability and other factors to take into account with solutions. There are countless resources out there for best practices of almost every aspect of SharePoint usage and development out there.
Not Doing Any Researching
As aforementioned, there are countless resources out there for best practice in SharePoint Development. There are also countless resources about the capabilities of the platform. And the capabilities of the tools. But the only way you will learn about this is by doing research. Start with the MSDN Developer Centre. Then search the interwebs for the area of SharePoint your working with, coupled with keywords such as “development, programmatically, sharepoint designer”.
Not Asking (The Right) Questions
We have all been there. If you’re a seasoned ASP.NET dev new to SharePoint, you’ve been there. When you were first put in front of an MVC project and told to learn it. Yesterday. There are plenty of places to ask questions. There’s SharePoint StackExchange, MSDN Forums, LinkedIn, and you can also ask the legion of Twitter users out there, by adding the hashtag #SPHelp to your question. You’ll get the best answers by asking the questions of the ilk “Where can I get info on…” or “What’s the best approach to…”, rather than “Give me code to do…”.
These five, and my little descriptions of each, are by no means in any way fully descriptive or exhaustive. There are many many more aspects that new developers need a hand with, and I believe it’s up to us experienced developers in the community to ensure that new developers aren’t left with a bad taste when it comes to developing in what is (when you get used to it), a pleasurable platform to develop on.