Use the Force Luke!

A bit of a sidetrack as I was planning to blog with pics on the mod for putting your image above the menu bar (I still don't agree with Heather that her solution works, nyah) so I will get to that, but later.

I did want to mention a couple of things about posting questions about SharePoint (in newsgroups, forums, wherever). First, please read your posts before you click the big send button. I don't know how many times we sit there trying to decipher a request when there's a typo in it. Really. It's quite simple. Proof read your post (being a blog, question on a forum, or an email) and make sure it sounds like it makes sense. Okay, maybe I'm guilty of this on my blog but like I said, there have been more times than I can remember where I've been reading the newsgroups and questions are being thrown about that make absolutely no sense. Relax, take your time, and read your own scribblings before you inject them onto the world. Gonzo journalism is great, but you need to master it before you can fire off posts without editing. Seriously. It will expedite the process of getting an answer if the guy on the other end of the line knows what you're asking.

Next is the big one. Recently there's been a pretty meaty selection of posts and emails with people asking if SharePoint can do this or SharePoint can do that. Some don't even ask if the tool can do it but rather go to the big, dark place of "I have to implement x using SharePoint or I'll get <fired | castrated | exiled | etc.>". Guys (and girls), hate to break it to you but SharePoint is not a shape-shifting, set your phasers on stun, beast from 20,000 fathoms tool that is all things to all people all of the time.

Yeah, drink that in for a minute.

It has custom lists, document libraries, it's web based, can version documents, has security, audiences, single-sign on, blah, blah, blah, blah, blah, blah. However it does not: make you dinner; vacuum your living room; teach your 7 year old tennis; play ball with your dog; impregnate your cat; dust your buffet and hutch; talk to your Xbox 360 (well, maybe); or generally do stuff it wasn't designed for. Yeah, it's a great tool and one that is very powerful but you, as an implementer of SharePoint need to know the design boundaries of it and stop ripping it apart to do your bidding. You wouldn't use your light sabre for grating cheese would you? So stop making your SharePoint deployment do crazy things. Yes, it *can* do it but *should* it? Probably not.

Give you a few examples. We all know that lookup lists are kind of clunky. The can only use lookup values from the current site, can't use calculated fields to lookup from, and they can't filter values in the lookup. These are design limitations. Live with it. Can you achieve these things? Sure. Write a wrapper to simulate the ListFormWebPart (i.e. rewrite it) and you make it do whatever you want. Write some funky JavaScript (like SharePoint doesn't have enough of this already) to filter your lists, call a web service, and otherwise rewrite the page on the fly. Create your own ISAPI filter to do what SharePoint doesn't do.

C'mon people. Give your head a shake. If the answer to your problem isn't already in front of you then maybe it's not something that you should try to do. There's being creative, then there's just bastardizing the tool to make it do something. That's not creative, it's just plain dumb. Does Microsoft Word do a great job of editing information that might be better suited for a spreadsheet? Then use Excel. Use the right tool for the right job.

Custom Web Parts can give you ultimate flexibility, but like anything they're expensive to develop. Yeah, even that 10 line Web Part to hide something on the page is 10 lines you have to feed, maintain, and grow. Update when the next version comes along. Add to version control. Document so when you get hit by a bus the next guy knows what it's used for. And so on. Development is fun but expensive so ask yourself if you can't solve a problem with an OOTB solution maybe adjust your problem (or it's parameters) so that it fits the technology you have to work from.

Web Parts will give you what you need, but at a price and too much of a good thing might be too much on a Web Part Page. 20 Web Parts on a single page, while they're all doing "important stuff" might take 30 seconds or so to render per person (as it's fetching data from all over the planet). Having this as your home page in your organization might just bring down your SharePoint server. Is this a design flaw or a launch problem? It's responsible development that you need to look at holistically and not just from the "I need x to solve my problem" type of approach.

In any case, you can achieve great things with a great tool but like any tool, you need to use it responsibly and with malice aforethought about what you're doing. Before you go off to build the uber-web part that will deliver everything under the sun, ask yourself if you really need it or can you leverage what you already have.

Software development is full of compromises and sometimes you just have to say no. No to the communications person screaming that they want their image on the right instead of the left. No to the HR person yelling that they want the form to dynamically change based on the users gender and way that they're sitting in the chair. No to the finance guy that wants to use SharePoint as his SAP replacement and do the entire corporations payroll with custom lists and 8,000 lines of JavaScript for the business calculations.

Trust me, you'll be better off in the long run.


  • Great post, I totally agree with you. The problem is that Microsoft has pitched SharePoint, and the marketing fluff that you read when researching SharePoint. I was expecting it to make my coffee when I first got into the office in the morning. I was just wondering where I configured the brand of coffee and how much cream.

    You said. &quot;So stop making your SharePoint deployment do crazy things. Yes, it *can* do it but *should* it? Probably not.&quot; I think that is a excellent point, but where is the list of should or should not. I keep hearing about, &quot;Well, it can do that.&quot; I haven't seen good list of what is should and shouldn't do.

    I am really trying to define that boundary in this next product that I am building, leveraging SharePoint. I am trying to figure out, what it should and shouldn't do. I haven't found much guidance, except try this and see if it works or not.

    Do you know of any good guidance on this?

  • Thanks for the feedback. I think it would be a tough list to put together but I'll see what I can do.

  • Great post. (I wouldn't get away with it)

    I especially like the first point and the last.

    I often wonder what people hope to achieve when they write a &quot;streams of consciousness&quot; posting which even when I read it three times continues to make no sense.

    But the last one is for me the key one.

    Learn to say No, guys. If you (SharePoint Expert) say it can't be done, people will believe you. Why say &quot;Yes I can do it but it will take some really nasty coding&quot; because all they will hear is &quot;Yes, I can do it.&quot;. Been there, done that. &quot;No&quot; is sooo much easier.

  • Hmmm. Well actually, I came to this blog to see if anyone had set up Sharepoint to do travel booking (i.e. travel agency self-service). I think this comment answers that. Thks.

  • HI. I have just started using Share point . Could you please tell me how much of data Share point can hanlde? Are there any restrictions on the data size that the application can handle?

Comments have been disabled for this content.