Welcome to OnSharePointDevelopment. I’m going to assume that you’re here for one of two reasons:
- You’re a SharePoint developer who is interested in improving his/her craft
- You’re an insomniac and this inane drivel helps you to finally fall asleep.
If the latter, feel free to keep reading until you nod off.
If the former, then let’s get down to business.
Why Are We Here?
I conceived of this site in the Fall of 2011 and started preparing presentations for the SharePoint user group I help to run. At the time, I was seeing a couple of trends develop in the SharePoint space, some of them encouraging, some of them discouraging. In either case, it was something that interested me and I felt like it was an area in which I could help. In no particular order, here’s what I noticed:
- We were at a watershed moment in SP Dev – a cusp or turning point. SharePoint is an extremely powerful product and a game changer in many ways. It brought about significant changes in the way IT operates and developers weren’t keeping pace
- Too much SharePoint development work was really, really horrible. Bad code is bad code, period. Unfortunately, the complexity and popularity of SharePoint have combined to produce an onslaught of really shoddy code and coding practices.
- SharePoint was not slowing down. I really thought that SharePoint would have peaked and begun slowing down by 2011. It hasn’t, and isn’t showing and signs of it, either.
- The Rise of the End User – SharePoint allows non- or less-technical end users to perform a dizzying array of customizations. While this is undeniably a good thing overall, it is not without its problems at the edges. The mantra of “just because you can doesn’t mean you should” applies, and is often the cause of friction.
- Extreme polarization – The dividing line between end user, developer and administrator is, oddly enough, simultaneously blurring and becoming more pronounced. SharePoint allows a significant amount of customization without requiring a single line of managed code. This allows non-developers to do things which historically required a developer. Instead of causing an amalgamation of professionals into a more homogenous “SharePoint Pro”, this has, for some reason, caused the stratification of SharePoint professionals and users into distinct “camps”, and anyone in a different camp is generally wrong. It’s remarkably similar to the dividing line drawn between Republicans and Democrats in the political arena.
A Journey of a Thousand Miles…
Paraphrasing Lao-tzu, the Chinese philosopher from the 6th century BC, a journey of a thousand miles begins with a single step. This is our collective first step… On SharePoint Development is a discussion on the what and why of SP Dev. It is my small attempt to help make us all better at our craft. There are dozens of decent sites/blogs/articles/books that can help you to figure out how to do anything you need to do in SharePoint. A simple Bing/Google search will return hundreds of results for any SharePoint-related query – some of them garbage, some of them gospel; most of them somewhere in between. What has been sorely missing, however, is an understanding of other aspects of getting the most out of this product, how to approach a problem, how to control process, how to get everyone on board and get the job done.
Rather than approach this in a scattershot manner, I’ve broken the journey down into sections:
- Development Process – a large portion of the beginning of this journey is going to be focused on this section. I’m doing this for two reasons – it’s currently the area that interests me the most, and it’s also, I believe, the area most sorely lacking. Writing code is easy. It’s all the other stuff of making that code good, efficient, reusable, repeatable, testable, manageable, fixable, etc that is hard.
- The SharePoint toolbox – SharePoint is the Prego of business software. (Just about) whatever you need…It’s In There. Understanding how best to use this tool and all that it gives you, however, is often where the problems come in. Too often, the immediate answer to the question “with SharePoint, how do I…” is it depends, followed be a litany of questions. Unfortunately, too often those questions are never asked and the developer runs off in the direction with which they are most comfortable, whether it is the right direction or not, only to find out later that their initial direction was flawed and they need to go back and start again. We need to fix this…
We’re all Padawan
I intentionally sub-titled this blog “Insights from a Journeyman Coder” as it’s important to acknowledge that we’re all still learning. I expect to learn as much in the process of writing the content on this site as you will from reading it.
What To Expect
The posts on this site are, for the most part, prose versions of the lectures I’m giving at my user group and other venues; not word-for-word transcripts as they’re augmented with additional detail, but close enough. All of the main concepts come across intact. As appropriate, I link to existing content elsewhere on the web to help drive home points.
I’ll warn you right up front that you’re not going to get a whole lot of “tips & tricks” on this site – there are FAR too many of those types of sites elsewhere and that’s part of the problem
What I’m hoping to Achieve
My goal for the content on this site is to make you think differently about what you’re doing. No longer is “make it work” an acceptable end-goal. I want us all to think about where we’re trying to get to and figure out the best route to get there.