How good/bad is sharepoint programming?

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'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'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.

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.

1. The users that we trained on it absolutely hated the user interface and it was very frustrating not to be able to fix the things that are wrong with it.
2. Customizing Sharepoint's visual presentation is not for the faint of heart. The incompetence of whoever wrote the CSS at Microsoft is just horrifying. I still have nightmares.
3. For whatever reason they didn't just design it as a garden-variety web app, which makes setting up a development environment a huge pain in the neck.

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.

good =============================[=]=== bad

• setup/administration/updating is a pain
• developing/debugging is a pain
• documentation is a joke

Sharepoint IS a huge mess.

1. The generated mark up is the worst I have ever seen.
2. It has equally bad CSS to go a long with that mark up.
3. God have mercy on the soul that has to restyle or extend the client side functionality of a sharepoint application.
4. The entire platform flies in the face of good architectural design.
5. Data Integrity is a huge problem with the platform, as there are no transactions.
6. The API is surprisingly bug infested and it won't take an hour after working with the API to run into bugs that will have you scouring the web and further exacerbating data integrity problems.
7. Proper unit testing is very difficult to do on the platform.
8. The platform is big and is cram packed with "everything", however everything Sharepoint does it does poorly. You could easily find other frameworks or platforms which do the job better and would be a much neater fit to your or your client's requirements.
9. The learning curve is steep, which would be fine if the documentation for the platform (especially the API) was any good.
10. Browser compatibility, Sharepoint is IE only (attributed to its horrendous markup, CSS and javascript).

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.

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.

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

1. It is a comphrensive platform. Makes it a hell lot faster to develop and deploy fully featured, standardized, scalable and high availability Web solutions like a corporate Intranet and Extranet.
2. It has huge momentum. Microsoft continues improving it and it gets much better with every release, the community is great and growing, online resources are good and growing, more and more books are coming out, many great free add-ons and good third-party products popping up all the time, and there are also great conferences to go to.
3. Very modular platform where you can package your own stuff into Solutions, features, Web parts, Templates, Content types and more.
4. It leverages standard Microsoft technologies like .NET, ASP.NET, IIS and SQL Server. So you will not get stuck with one specific skill set.
5. In the current job market, you are much better off with .NET + SharePoint skills than just .NET skills. It is something like saying you have SAP experience or are a BI specialist.

Top 5 Bad Things about SharePoint

1. Steep learning curve. It takes at least two years to become a good SharePoint developer - even if you are already good at C# and .NET. You will need the first year to just understand all the concepts in the platform and then another year to get really familiar with them.
2. Inadequate development tools. Visual Studio hardly knows anything about SharePoint - but I hear this is going to change big time with VS 2010 :-)
3. Not always possible to use the latest and coolest .NET features. It always takes SharePoint a few years to adopt the latest and greatest stuff from the .NET platform teams. Just think about Linq and AJAX. I am curious to see if/when SharePoint 2010 will support .NET 4.0.
4. Often a need to find work-arounds to quirky problems/inconsistencies in the platform.
5. Changing APIs. Well, at least this was a pain moving from SPS 2003 to MOSS 2007. I hope the transition to SharePoint 2010 will be a smoother ride.

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 am 3 months into a SharePoint project that will be ending soon.

I spend my days going through error logs trying to figure out why various SharePoint components do not function like MS says they should. Documentation is regarded by many in development industry as "...worst I've ever seen". Good luck finding anything useful on an MS related site.

Many "social features" depend on UPS (User Profile Service) which is notoriously buggy and difficult to configure; google it and you'll see. On my project it took multiple developers weeks and a Ph.D in EE to get UPS working at all. All this for a webservice! Due to ongoing stability problems said company eventually hired a SharePoint author who proclaimed "I believe in this platform!". Yea right. I wonder how much he's getting paid to say that. However take heart, with each new MS Cummulative Update, UPS gets closer and closer to being viable, at least for a development environment. It has come a long way from the initial release when it completely didn't work at all.

You will spend much of your time configuring Active Directory, IIS, ForeFront Identity Management Services, SQLServer, and Server2008 settings. Keep in mind most of these settings will conflict with one another so be prepared to spend plenty of time on SharePoint blogs looking for work-arounds. In fact most SharePoint blogs are dedicated to workarounds and hacks just to get SharePoint to work or at least bring it up to functionality of basic website. I thought the whole point of a platform with pre-built functionality was to decrease your work load, not increase it. If you like to lay code and not play admin or blog sleuth, this is not the platform for you.

As mentioned elsewhere development requirements are insane. SharePoint Server(the full version of the product) can/should only be run on Windows server. For me this means virtual machine. 8GB ram is really minimum you can get away with. I ended up buying core i5, 16GB, and SSD just to build reasonably fast dev environment. This is web development, not video editing.

If you and/or your team are lucky enough to get SharePoint mildly stable in a production environment, end users will be treated to 5-second page loads, slow response times for almost any type of request, and possibly the most unintuitive UI in recent computing history. One of SharePoint's major attractions is that you can edit web pages on the fly by adding various types of webparts or using SharePoint Designer to actually change structure of page. This can get experienced developers into a lot of trouble so non-technical user's whom I believe this feature is targeted towards, will die. They will be met with a chorus of Correlation Id errors that give them a very helpful and informative GUID.

Developers and end users both loose when it comes to this mess. The only thing SharePoint is good for is making me believe in necessity of opensource.

PS - Please don't attack my spelling or grammar. I am not an English major.

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.

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.

It's a (good?) way to pay the bills....

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.

It's clear from the other answers that there's a lot of frustration for SharePoint developers.

The givens are:

1. Yes you have to develop on a server product Windows 2003 or Windows 2008
2. A lot of development information comes from blogs of varying quality
3. The product tries to be everything to everyone but the reality is that the product is so large there are areas of speciality required

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!

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.

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 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?

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