SharePoint Development – is it too easy?
I was chatting to some community folk in the pub last night after presenting (on Architectural patterns on S+S – slides here) at the Sydney Deep .NET User Group*. I heard an interesting premise: “Good developers don’t want to do SharePoint development because it’s too easy”. To me, this passes the smell test. Developers like a challenge. As Nick intimated in his session on home-grown frameworks last night, there’s a significant proportion of developer work that happens because the devs enjoy solving the technical problems associated with, say, generalising access to back-end data sources.
I hate to tell you, but someone’s already solved that problem! It really is all about the platform.
Of course, this begs the question: “what about the move to model-driven development and composable applications?” Will developers be able to work by getting components and just linking them together? Discuss.
If you want to learn more about SharePoint development, you could do a lot worse than visiting:
* the site’s down temporarily, but will be back “rsn”
Comments
- Anonymous
December 04, 2008
LOL "too easy". Have they tried it?Rather than burning hours of time writing the underlying frameworks, they can take what the Platform gives them and invest that time in extra functionality. Most projects I've worked on we always spend weeks building the same old stuff over and over again: Data Layer, Business Objects, CRUD UI etc. There are code generators out there that will help with this, but why bother when you can Leverage the SharePoint Platform.Would also recommend reading my Leveraging the SharePoint Platform posts if anyone is interested:<a href="http://sharepointmagazine.net/technical/development/leveraging-the-sharepoint-platform-part-1">http://sharepointmagazine.net/technical/development/leveraging-the-sharepoint-platform-part-1</a>Also some other good ASP.NET -> SharePoint Dev resources here:<A href="http://wss.made4the.net/archive/2008/11/10/sharepoint-developer-resources-not-to-be-missed-not-just-a-repeat-announcement-of-sharepoint-guidance-.aspx">http://wss.made4the.net/archive/2008/11/10/sharepoint-developer-resources-not-to-be-missed-not-just-a-repeat-announcement-of-sharepoint-guidance-.aspx</a> - Anonymous
December 04, 2008
AMEN JT!For me, a good developer is lazy - don't redo stuff that's already been done. Spend your time adding value, not reinventing the wheel. Also, there must be some level of cognitive dissonance when individual developers reckon their implementation of <insert platform functionality here> is better/more efficient/faster/more robust than what's provided by the platform.sigh - Anonymous
December 04, 2008
I wouldn't say SP development is easy for the usual developer. I would say convoluted more than anything. Even w/ the Visual Studio extensions, the toolset just isn't there. The VPP makes any kind of development cumbersome. - Anonymous
December 04, 2008
I wouldn't say SP development is easy for the usual developer. I would say convoluted more than anything. Even w/ the Visual Studio extensions, the toolset just isn't there. The VPP makes any kind of development cumbersome.Seconded. From a developer's perspective, SP is a mess. It is badly documented: half of class reference on MSDN consists of blank articles, absolutely crucial stuff such as LookupId CAML attribute is not even mentioned, etc. It walks over all Framework Design Guidelines - properties that return a different object every time you call them, and, as a bonus, the caller must dispose every object returned - eek! Dismal error reporting - when you do something wrong, depending on your luck, you get either COMException or SPException with an incomprehensible error message giving little indication as to what went wrong.And yes, the lack of proper tooling is also a big deal. VSeWSS is there, but it still can't do half of what's needed (it can't properly deal with resource files, for example, so for localized projects it's right out), and we still can't design .aspx pages using the proper Visual Studio editor for them. - Anonymous
December 04, 2008
Steve, I agree.Paul Andrew (http://blogs.msdn.com/pandrew) has been doing some good work to make these things better, but I agree we're not completely there yet.BTW, I'm not necessarilly agreeing with the premise that was put to me last night, it's just not one I'd considered before and am interested in exploring it.Cheers - Anonymous
December 04, 2008
I think it depends on what you are trying to do.There is alot of stuff that is easy in SharePoint. But bear in mind that SharePoint runs on ASP.Net so effectively any application you embedd into SharePoint is not only an ASP.Net application (following Architectural Patterns) but also has the added complexity of integrating with the SharePoint Environment (Updating lists etc).If you want to create somewhere to store documents and version control them then yes. SharePoint development is easy, but ideally one would want the business user to create the documet library and not the Developers.If I had to be negative about SharePoint development I'd say the WSS API's behaviour is random at times, not easy.In this case Architectural Patterns are needed MORESO to abstract out the WSS API's funnies.My experience has been that following patterns has made SharePoint development easier. For example if we have one IRepository interface and both our SharePointRepository and SQLRepository use the same interface it makes our development cycle smoother. I think whoever made that comment has not done much SharePoint development... or perhaps I'm just a bad developer;) - Anonymous
December 05, 2008
I think the term "easy" is likely referring more to "SharePoint customization" solutions than "SharePoint development" solutions.Both types of solutions, in my opinion, benefit from developers less interested in "tech/code" and more interested in "business". - Anonymous
December 05, 2008
The comment has been removed - Anonymous
December 05, 2008
Ok here's time for a plug...so I released http://www.sharepointdevwiki.com/ this week which hopefully will encourage others to share their experiences in a structured way rather than chronologically on blogs or forums which can be a pain to find or know whether its authoritative or not. Please check it out and feel free to join the discussions on structure and our target audience. - Anonymous
December 11, 2008
Amen, Tom. 'SharePoint Development' is too all-encompassing to label with one brush such as 'easy' or 'hard'.A comprehensive solution often requires efforts across the spectrum, from customization-type activities, to feature development, to custom page development, etc., etc. Each of those efforts has a different level of complexity associated with it.I believe that too often, people's lack of understanding that SharePoint is a platform and not just an application leads them to think that most solutions can be done as mostly customizationconfiguration. If you want silo'd, patchwork, non-scalable solution, sure, and maybe that's what you need sometimes. But development requirements for scalable, maintainable solutions leave the 'customization only' realm very quickly.