I rarely engage into debates with lunatics.  A wise man once told me that anyone who argues with an insane person is themselves insane.  As a result I’ve had a natural bias against engaging in religious wars directly.  When I do engage in religious wars (see “Open Source Software on the Desktop – Is it Right for You”) I generally do my homework.  I try to see all the sides of the equation as I can.  In the case of Linux vs. Windows – I ran both on my servers and on my workstations.  I ran them both for years before writing about it.  When I had reached my conclusions I validated them with someone who held a seemingly contrary position.  I did all of this because I try to avoid the insanity and stick with the facts.

I do currently host a few DotNetNuke sites on one of my servers.  Nothing really big but enough to matter but certainly enough to give me a sense for what the technology does.  I did a tech edit for the Beginning DotNetNuke Skinning and Design.  I certainly am not the foremost authority on DotNetNuke.  However, I do know a few people now who are authorities on the technology.  I learned a lot from my experiences with the product while getting it setup – and in working with it for the book.

I have spent a bit of time with Community Server – not nearly enough, however, I have great respect for Rob Howard and the guys at Telligent.  Do I believe that I can accurately articulate what Community Server does and does not do well – nope.  However, am I still trying to learn more about it – yep!

Why am I making a point to tell you about the related and semi-related products that I am paying attention to – and how I’m paying attention to them?  Honestly, because I am hoping that before writing another “SharePoint Sucks” blog post that someone will pause and really understand the platform first.  Even the short snippets I write about SharePoint I try to do with a balanced hand.  My End Bracket “You Should Learn SharePoint” article in MSDN magazine didn’t just mention the positives, I also highlighted some of the real issues that developers face.

I guarantee that there are issues with SharePoint.  I’ve got a list longer than my arm of things I want to see changed.  Some of them I communicate to MS – and some of them I silently live with – because I realize that there’s a reason why they did something the way they did and it’s better for the product to do it the way that they did – even if it inconveniences me, my scenario, or my customer.

I’m not saying that there aren’t truly bonehead things in SharePoint – there are.  Invite you to try to find them – and tell the product team about them when you find them.  (If you can’t get them I’m happy to hear from you and pass along reasonable, well articulated issues for you.)  What I’m saying is that for every bonehead thing that I find I find dozens of other things that exist for a reason.

The thing is that product development isn’t about absolutes.  No product team knows what everyone will do – or want to do – with the product.  They have finite resources and finite input on a product.  They have to compromise and build the best product they can.  It will have warts.  It will have gaps.  It will have bad spots.  The trick isn’t creating a product without these – the trick is putting them in the least intrusive places.

So let me it a few common complaints about SharePoint and provide my canned responses so you can skip the time of writing a half-thought out blog post if that’s your intention.

1)      It’s too complex – You’re right.  Anything that is flexible is.  SharePoint is very flexible and is therefore necessarily complex.  I’m not going to insult your intelligence to tell you that it’s easy – it’s not.  I learn more about it every day.  However, it’s a big product family and you can stay tactically focused and only learn those things that apply to your situation – if you want.  Here’s a quick list of questions and answers on the complexity of SharePoint in no particular order.

a.       Do you have to know XSLT to work with SharePoint? – not really unless you want to work with the out of the box web parts.

b.      Do you have to know XML to work with SharePoint – probably. 

c.       Does that XML knowledge surpass most people’s understanding? – at times. Yes – most folks don’t understand namespaces in XML and in some places it’s important to SharePoint.  This occurs most notably in web part configuration .  i.e.  .webpart – files.

d.      Do you have to understand Code Access Security? – Yes, but frankly if you’re developing a web application in ASP.NET you should know this.  You don’t have to write CAS policies if you’re willing to deploy everything to the GAC.

e.      Do you have to know ISA Server, Active Directory, Indexing, SQL Server, IIS, etc.?  — No not really.  Sure it helps but I wouldn’t say that you “have” to know these things.

f.        Do you have to know Master Pages?  — Only if you want to brand the pages or change the layout – if you don’t worry about that for your ASP.NET applications then you don’t have to worry about it with SharePoint.

g.       Is it hard to install? – Nope.  The standard windows  installer where you hit next a bunch of times and it will finish.  Sure if you install it in a complex configuration it will prompt you for a fair amount of data but by and large it will configure itself if you’re willing to take the defaults.

2)      It doesn’t do X as well as Y.  One of the things that I run into repeatedly is the thinking that SharePoint should be better than targeted applications.  These applications have on niche (or at least narrow) market that they are targeted for.  They solve one problem.  They’re not flexible.  They can’t be configured or reconfigured by users.  However, they do their one thing better than any other application.  When you compare SharePoint side-by-side with applications like this you can determine all sorts of ways where SharePoint doesn’t measure up.  However, that misses the point.  SharePoint is a general purpose tool that can be made to do several things – in many cases well above the “good enough” bar to make it a viable solution.  Sure the dedicated application may do a better job with some things.  There’s no doubt.  However, what’s the better answer from a organization perspective.  One product that solves many problems, is flexible, and has tight integration to Office – or a set of individual products that may each individually do slightly better at solving one or two problems but come with a set of integration, synchronization, and disaster recovery issues?  There isn’t one answer here – just a realization that you have to think about the greater good.

3)      SharePoint didn’t eliminate my need to organize my information.  I love this one.  It always leads me to Fred Brooks “No Silver Bullet: essence and accidents in software engineering.”  The reason is because there are no silver bullets.  SharePoint won’t eliminate the need to organize information – it will: minimize the need to have fully defined content taxonomies by leveraging full text search.  It will create new opportunities for organization by allowing the multi-dimensional aspects of metadata based organization, and by improving context.  If you have a bad taxonomy today, SharePoint will make it easier to find the information you’re looking for – however, it won’t make it possible to find everything every time.

4)      SharePoint didn’t automate my company.  No, SharePoint doesn’t do the truly hard work – it allows the hard work to happen.  SharePoint won’t magically define all of your workflows.  It won’t define metadata for each of your document types.  It won’t establish information rights management policies across the organization.  However, since it can do these things it becomes possible to have the hard conversations that lead to the results you want.  With the traditional network shares technologies there’s no opportunity for workflow, adding metadata, or automatic assignment of information rights management policies so there is little reason to even entertain the conversations.  It’s honestly a “the chicken and the egg” problem.  You can’t define the processes until you have a tool that can implement them – and you can’t fully implement the tool until you have the processes.  Jason Mraz has a song, Live is Wonderful that has much better examples than “chicken and the egg” but they’re less known.

I’m assuming that if you’ve read this far you’re saying “but you’re just defending SharePoint.”  I’ll take that criticism but I would ask that you look back at my responses – I’m really just defending the process of building software.  SharePoint is a flexible, general purpose, highly integrated tool.  It’s not for every situation and it won’t do the hard work of building taxonomies and it won’t automate your company.

For those developers who want to insist that it’s a hard platform to develop for, I agree within context.  Today we’re used to IDEs that do all of the heavy lifting for us.  We absolutely expect that we can hit F5 and compile, deploy, and test our work.  It’s not that way with SharePoint.  Absolutely we need better development tools for SharePoint.  However, that’s fixable without condemning SharePoint.

I “grew up” professionally programming on a VAX and on a PC in C.  I learned how to use print statements to know what my software was doing.  I didn’t have interactive debuggers.  I didn’t have the ability to set breakpoints.  I learned how to develop without these tools.  The problem is that most developers today never learned these skills.  Because of that if there isn’t an interactive debugger developers don’t know what to do.  I feel sorry for them.  I don’t like debugging with print statements – but I feel like it makes me a better developer to know how – and when – to do this.

So SharePoint isn’t perfect, but what is?