Geeks With Blogs

News
G's Blog Problems and (Hopefully) Solutions in Development

I’m being pressured by a very non-technical program manager to work with another team to “integrate” our current ASP.NET application set into a non-existent SharePoint 2007 solution. The main problem I have with this is that this SharePoint solution has been sold to leadership by a smooth talking faux-developer. By this, I mean that this guy truly believes that he’s a software developer, but in reality his development career has consisted of scripts for servers, not actual OO-development, but I digress.

 

I’ve spoken to a handful of developers who have developed for SharePoint and have a few close friends who have had this “privilege”; none of these people described a good development experience to me. Am I being bias? Perhaps, but I’ve got nothing else to go on. So, this is a call out to my technical colleagues out there in the blogosphere. Please, give me input, positive or negative, about your experiences with SharePoint development.

 

I need this information so I can either get off of my soap box and buy in to the SharePoint idea, or gain more ammunition to fight off this potential disaster.

Posted on Monday, May 4, 2009 10:25 PM .NET | Back to top


Comments on this post: To Sharepoint or not to Sharepoint

# re: To Sharepoint or not to Sharepoint
Requesting Gravatar...
glenn- remember the mess we called Sharepoint at NW3C - the free version... clear as mud.
Have fun with that!
Left by Tim on May 05, 2009 7:04 AM

# re: To Sharepoint or not to Sharepoint
Requesting Gravatar...
In a nut shell buy into the idea.

In a worst case senario you can take just about any asp.net application and stick it in your own folder in the /layouts - you might have some issues with links and a few other things but for the most part it's not as bad as you might think.

On the upside, lets say you do start to buy into the idea. Start leveraging SharePoint as a platform. Then you get a lot:
You get things that are built in, think of it as software infrustructure - like users, and libraries and lists, pages, features, all kinds of wonderful good stuff that you don't have to write any code around.
Features - An already proven deployment senario. So now you can just cencentrate on your functionality and not have to worry about how you're going to push it out.
Libraries and lists - all this CRUD is done and users are just off and running, you can access this data or port it, but you didn't have to mess around with them while they don't know what they to build.
Workflow - Same as above.
all the richness of asp.net - plus a whole lot more, so now you are more of a component developer instead of an application developer - the app defv is now a BA or someone is some department iwth a specific problem.
There's only 8 lines in this window but I could go on and on. On the down side? yeah sure there's a few things. Even around the topics I've just mentioned, but I think what happens is that you get down the road much further much quite to discover problems that are more mature than if you have to build everyhting yourself.
One other note, if you build an application yourself, people are still going to have to learn it weather it's SharePoint or some application you wrote. Chances are pretty good that you'll come across a lot more people that have used SharePoint and understand it's various user interface assest and functionality.

Left by Stacy Draper on May 11, 2009 3:49 PM

Your comment:
 (will show your gravatar)


Copyright © Glen Skinner | Powered by: GeeksWithBlogs.net