I got a job offer today for a position as a SharePoint developer. One of my friends is telling me that sharepoint is a big mess and not something I would want to be doing.
What are some of your experiences/thoughts in working with SharePoint?
I got a job offer today for a position as a SharePoint developer. One of my friends is telling me that sharepoint is a big mess and not something I would want to be doing.
What are some of your experiences/thoughts in working with SharePoint?
SharePoint can be frustrating at times. It's a "maturing product" according to Microsoft, so when you do something wrong, you get nice errors like "an error occurred" or "cannot complete action". CAML is something that requires great patience. The documentation on it is not very good and you can waste a great deal of time over a stupid syntax error.
All in all, it's a decent platform, but it will probably cause you to get gray hair sooner than your peers.
SharePoint is a v2 product...v3 is due in 2010, and it's the fastest growing product in MS's history (supposedly). v2 is short of mature, and it definitely leaves something to be desired for those of us who develop, but there's a lot of tools out there that make developing against it easier (stsdev, being one).
It's something that you'll be seeing more and more of if you stay in the Windows realm. It's a powerful platform and the future of it looks very promising.
From a developer's perspective, it's a bit frustrating that they've thought about developing against it as sort of an afterthought, as most Windows-based applications are. The end user wins in priority, that's for sure.
SharePoint work is challenging and rewarding, even without the development aspect of it. You're affecting the entire organization and actually helping businesses run better. The development aspect will frustrate you from time to time, but it all tends to even out.
It varies a lot depending on the way the project is run - if you work within the design of SharePoint you can achieve a lot without much effort. If you get requirements that go against that and the client isn't willing to compromise, it can get pretty frustrating.
You also tend to get a lot of environments that haven't been set up right - even things as basic as source control and reproducible deployment are often left out. The infrastructure people often don't understand SharePoint, so you get issues like not being able to connect your development environment to a network.
However, most of these issues are quite easily solved if there is someone involved who knows what they are doing. Once you get past any project and environment issues it's quite a good platform to work with.
The official documentation isn't particularly helpful, but the available unofficial documentation and tools have improved a huge amount since I started working with the platform.
If you have a background in web development, I think you might be frustrated at the lack of flexibility that Sharepoint offers developers. Being restricted to think in terms of "web parts", isn't a lot of fun if you've previously had the flexibility to write a little closer to the HTML.
In addition, I found that a lot of time was spent on configuration / implementation issues, relative to regular web development.
You do get a reasonable amount of functionality "out of the box" though.
I'm surprised at all of the positive responses. Let me just ask, do you mind creating your markup in code? As in HtmlWriter.BeginTag("br") (or whatever, sorry for not knowing the HtmlWriter api). That's considered best practices for creating redistributable web parts.
How about the Ajax Toolkit? Oops, off limits. Doesn't work due to a missing doc-type in the header.
And your laptop is running Windows server 2003, right? Because of course Sharepoint won't run on anything else.
I understand people defending their platform, but as someone who has had to do some work in Sharepoint, but doesn't any more ... let me say that developing for Sharepoint is the worst development experience of my life. Now, I've been pretty careful in my choices to date, so it's not the worst possible experience, but it's down there. Or, to put it another way, I would much prefer working in PHP than Sharepoint.
It's simultaneously the most frustrating and the most rewarding experience you'll have. While the reward comes (at least partially) in the form of a great salary (compared to straight web dev), the frustrations are nothing that can't be overcome with stackoverflow and google at your side.
I've been doing SharePoint development since 2003, and the valleys of "I FREAKING HATE SHAREPOINT!" are always off-set by the moments of "DUDE, THAT'S FREAKING AWESOME!"
If you are offered an entry-level position doing SharePoint, I'd take it in a heartbeat. You'll get on-the-job training on one of the hottest technologies around.
My small web shop briefly embraced SharePoint a couple of years back; we did consulting, customization, training, and so on. It's true that you get a lot out the box, and I understand it's improved a lot; but the overall experience was very negative and we've never looked back.
In general, SharePoint falls short of its promise in a number of ways that are just mystifying: Things that would seem like no-brainers require all kinds of custom development.
We've gone back to rolling our own solutions for customers; they're much happier with that arrangement, and so are we.
I knew nothing about SharePoint 3 months ago. Since then I've had to create a couple of custom web parts for my company's new support site and I have to agree with your friend, it's a big mess.
At first I was impressed by how much you could do with the platform without any coding at all. But it's been frustrating getting my stuff to work properly. I tried to incorporate a user control I had written earlier that worked great in a regular web app, but a key part simply wouldn't work in SharePoint for reasons that are still beyond me. I managed to find a workaround, but lost two weeks in the process.
It was also disheartening to learn that the development environment has to be a machine actually running SharePoint, which has to run under Windows 2003/2008. I had to set up a virtual machine on my existing system, which isn't a big deal but it's one more hurdle you have to overcome.
In all, it seemed way too confusing for what you're trying to do. I agree with the sentiment that a lot of time is spent on installation, configuration, and deployment versus actual development. Maybe the 2010 version will be better. It's certainly not a product I would look forward to working with.
I'm going to buck the trend here a bit. I see SharePoint as a development platform - plain and simple. It utilizes other technologies such as IIS, ASP.NET, SQL Server, and Windows Workflow so I don't have to reinvent the wheel. It lets me focus on solving business problems instead of worrying about plumbing and system-level code.
Don't get me wrong, SharePoint does come with baggage, but if you like to solve real-world business problems and not just sling code, it has a lot to offer. I am continuously amazed at how rich the platform is with WSSv3 - which is free.
If you like to align yourself with Microsoft technology, then you need to realize that SharePoint is here to stay and will continue to get better and be more commonplace. The current version (v3 - WSSv3 / MOSS 2007) is lacking in AJAX, social networking, and other functionality/technology. The v4 version is just around the corner and is bound to improve in these areas.
In regards to some of the negatives I have read in this thread:
I have written web parts that live in SharePoint that utilize the AJAX toolkit and so have co-workers of mine. One co-worker is very active with Silverlight web parts.
Yes, you do tend to develop on Windows Server 2003/2008. This doesn't bother me and I don't spend much time at all on installation and configuration. I do use virtual machines for development environments sometimes and agree that can sometimes be a pain.
What I am able to do, however, is configure some things instead of develop. Authorization, done; provisioning, done; row-level security, done; basic UI CRUD, done; deployment to multiple front ends, done; search, done. Now I have time to focus on solving the business problem.
If you are going to do SharePoint development, you need to get started on the right foot. I highly recommend Inside Microsoft Windows SharePoint Server 3.0 to get to the meat of what a developer can/should do within SharePoint.
For what it's worth, I've been a developer for over 20 years working on Unix and Windows in several different languages and technology. I've been focusing on SharePoint v3 since it's beta days and am happy with the direction I have chosen.
I am happy to report having a positive experience with SharePoint programming. I agree that the out-of-the box masterpages and css are pretty bad, and the here and there lack of documentation in the API can be very frustrating at sometimes, but these are minor setbacks if you see SharePoint as a development framework instead as a finite product which can be customized. I have read someone at MS describing the SharePoint as "modeling clay", with the out-of-the-box templates merely as "demos" of what can be achieved.
I find it quite easy and straightforward to build a custom master page (with the proper Doc Type in the header to remove the awful BackCompat and enable CSS1Compat, for example) or have my aspx pages with code-behind or whatever. Bottom line is - whatever you can do within a website in pure asp.net 2.0, you can do the same with SharePoint and benefit from its scalability, deployment techniques, API, permission model, audits, document storage system, InfoPath integration, workflows, etc.
I guess that in the end it really depends on your point of view: is SharePoint a development platform with a "demo" collection of site templates, or just a semi-finite product which allows you to customize it here and there?
It's clear from the other answers that there's a lot of frustration for SharePoint developers.
The givens are:
It is definitely a technology that is still maturing for developers. The amount of information available from the developer community and Microsoft has grown enormously in the last 2 years. There's a lot of guidance coming out of the patterns & practices team for SharePoint which can be found here: http://www.codeplex.com/spg
As for some of the other comments - it's the fastest growing Microsoft product measured on licenses sold, not necessarily on installations! And yes, the functionality that comes with WSS 3.0 for free is pretty amazing.
There's a very wide scope of what 'SharePoint development' could encompass. It could be pure web content development driven through the web browser and tools like SharePoint Designer. Or getting down and dirty writing custom ASP.NET web parts, Windows Workflow, custom ASP.NET web services and pages hosted in SharePoint and much more.
There are a lot of out-of-the-box web services that come with SharePoint that allow integration with other systems and some people might call programming against that API 'SharePoint development'.
I think the rule of thumb with SharePoint in general is that on the surface it appears to be an all encompassing product that tries to be everything to anyone. Sometimes you don't have to scratch the surface very far to realise that the platform isn't going to solve your particular business needs without significant customisation. It's sometimes that last 10% of required feature that costs you 90% of the effort!
good =============================[=]=== bad
I have like Kirk also worked with SharePoint since the 2003 beta version and am still liking it. You can of course always wish for something to have been better thought through - but I guess you can say that about almost any Enterprise product. To me, the positives far outweight the negatives when it comes to building solutions on top of the SharePoint platform.
Let me as a developer share with you my top 5 good things and top 5 bad things about SharePoint:
Top 5 Good Things about SharePoint
and #6: more girls involved in SharePoint projects (Maybe this should have been #1 ;-)). Women typically handle many of the softer aspects of big SharePoint projects, which they are often better at than their male counterparts. A successful SharePoint project is sooo much more than coding some Web parts and styling some Web pages. Just read the excellent series Why do SharePoint Projects Fail by Paul Culmsee.
Top 5 Bad Things about SharePoint
I find that the biggest frustration with SharePoint, even the latest release, is the lack of attention to documentation. There are so many poorly-documented API calls. I can feel my blood pressure rising just from posting this answer.
Definnately a good technology and i think this may be the future of most of the website/ web apps!
Let's se what Sharepoint 2010 has got for us!
I was originally an ASP.NET developer building Web Content Management Systems and working with Document Management Systems. SharePoint was a natural progression in this space leveraging on the skills that I already had on top of a platform.
I did a presentation on this last year that may be of interest.
More information is available here: http://sharepointdevwiki.com/x/HYBfAQ
I have decent .net dev experience and 3 months on SP, my experience so far:
The good:
I think SP is good for application with simple data model, preferably read-heavy. A huge strong point is what users/administrators can achieve with configuration only. Change data structure on the fly, modify look and feel, etc. A wonderful platform for "my books" kind of things..
The bad:
But there are lot of things where SP stumbles and falls (on you). For example it is hard to work when non-trivial logic is required, especially aggregation functions over foreign key relationships. And of course the lack of transactions. Maintaining data integrity could become a problem. Beware of this when you consider working on a specific project.
There's little compile-time support, majority of your tasks will include messing with resources looked up by calling it by name as a string. It can be considered "flexible" and "simple", but its just too error-prune for my taste and slows down development. Of course this is not only SP thing, but MVC/webforms seem more easily pushable toward the strongly typed world.
If you like managed world then deal with the fact that the vast majority of SP is non-managed code, giving you exceptions like "HResult 8000072F" with next to no stacktrace to hint you on what could have failed.
Deployment and bug reproducibility has caused quite many frustrating days. WSS takes the whole machine for itself, files needed to run the app are scattered around DB, file system (and quite often GAC). To have a basic separation of projects, expect to be working on lots of different VMs.
The tool support is quite poor (not tried VS 2010). Better expect to make friends with command line and scripting. Expect debugging experience to be slow. Unit-testing is quite hard to do..
My personal conclusion: SP has it's niche but it is not a platform a .Net programmer can enjoy. The user experience may have some occasional "WOW", but the developer experience did not. This could be the "steep learning curve" talking, but maybe it's just the way it is.
Sharepoint IS a huge mess.
It has to be said, the platform makes money, but more as a money making scheme. Developer skills in Sharepoint are rare and people with those skills are paid well. Clients pay through their teeth for Sharepoint custom dev and development houses as a result do their best to convince their clients that Sharepoint is the perfect fit for everything.
My opinion, Sharepoint is not a development platform, but a money making platform.
Edit: I also forgot to add 11. Its a resource pig like nothing you've ever seen before.