On Presenting
I just finished a presentation tonight at ETNUG called "SharePoint Sucks!" The presentation was my entry into Speakers Idol, where people who weren't selected as speakers for Codestock session could compete for one last remaining session. Didn't win, but it did net me the presentation at the August ETNUG meeting.
Incidentally, for those interested, here are the links I referenced as resources:
- Downloadable WSS books from Microsoft
- 7 Development Projects for SharePoint (PDF)
- CleverWorkarounds.com - lots of good SharePoint articles, including "Why Do SharePoint Projects Fail" series
- EndUserSharePoint.com - "Thinking SharePoint" series
- SharePoint Server 2007 Best Practices
- WSS3 Evaluation Virtual PC image
- MOSS2007 Evaluation Virtual PC image
The topic, contrary to its name, was about when to use and when not to use SharePoint. (If you really want to know where the title comes from, go through the comments on some of my SharePoint posts.) It's been quite a while since I've had to present anything, so I've been critiquing the whole experience.
One suggestion I received is to ditch the "Intro to Windows SharePoint Services 3" topic I originally submitted, and go with a continuation of "SharePoint Sucks!" for August's ETNUG meeting. I'm not completely comfortable with this idea, because I don't feel that approach is quite my style.
On the other hand, I have found out that I'm much more comfortable at Q&A and discussion than I am at presenting all my own stuff. I think it's because I like thinking inside the box, so to speak. Q&A forces me to tackle the questions that people need to know rather than trying to do an overview that's simultaneously broad and deep. In turn, this keeps me from overanalyzing details or going off on tangents. Extending the "SharePoint Sucks" talk should naturally lead to better discussion. (Maybe.)
So I'm kind of at a loss as to which way to go for the August meeting right now.
I noticed an interesting side effect after presenting that I'm not sure I like. Preparation for a presentation will usually be stretched out over a few days. So by the time the presentation rolls around, you've been living in this world where your topic is The Most Important Thing Ever. And once it's over and the rush sort of drains out of your system, your priorities correct themselves and you realize just how insignificant your topic is in the larger scheme of things. It almost makes the presentation itself seem silly.
And yes, I know this post is completely breaking the fourth wall in ways good bloggers shouldn't. But that's because it might mess up their space suits.
Comments
Yes expound on it
I've got my own thoughts brewing on what I call "Bad Ideas in SharePoint". There's a second direction you can take your presentation, "What the books don't tell you about SharePoint".
Between these two things, you should have good material.
Examples of "Bad Ideas in SharePoint":
* using SharePoint as your "everything" development platform, i.e. everything goes into SharePoint
* Just because you bought something, doesn't mean you need to use it - i.e. don't just use Excel Services now that you have it. Don't try to put everything in InfoPath even if you bought Forms Services.
* The idea that you should use Silverlight in SharePoint: give it a while, it's not ready.
What books don't tell you about SharePoint:
* Visual Studio workflow is ridiculously painful
* SPD workflow is nice but you will not be able to use it for most of your apps
* No one uses just VSeWSS, no one.
- Corollary: U2U CAML tool - if you're writing a CAML query, you need this.
* Priority one is to find out if some SharePoint feature solves your problem, before you code something up. E.g., before you code up an employee search app, look around at what SharePoint offers.
* If you search and can't find anything about the SharePoint framework class
you're attempting to use, you should probably take another approach.
* Don't be ashamed if you don't store your app data in SPLists. You can get the "runs in SharePoint" checkmark many ways, some of which are so easy and effective they may surprise you.
I need to write this up on my blog and flesh it out some more.
Between these two things, you should have good material.
Examples of "Bad Ideas in SharePoint":
* using SharePoint as your "everything" development platform, i.e. everything goes into SharePoint
* Just because you bought something, doesn't mean you need to use it - i.e. don't just use Excel Services now that you have it. Don't try to put everything in InfoPath even if you bought Forms Services.
* The idea that you should use Silverlight in SharePoint: give it a while, it's not ready.
What books don't tell you about SharePoint:
* Visual Studio workflow is ridiculously painful
* SPD workflow is nice but you will not be able to use it for most of your apps
* No one uses just VSeWSS, no one.
- Corollary: U2U CAML tool - if you're writing a CAML query, you need this.
* Priority one is to find out if some SharePoint feature solves your problem, before you code something up. E.g., before you code up an employee search app, look around at what SharePoint offers.
* If you search and can't find anything about the SharePoint framework class
you're attempting to use, you should probably take another approach.
* Don't be ashamed if you don't store your app data in SPLists. You can get the "runs in SharePoint" checkmark many ways, some of which are so easy and effective they may surprise you.
I need to write this up on my blog and flesh it out some more.
"Bad Ideas in SharePoint"
Actually, that sounds a lot like what I was going for. If you want my slide deck for "SharePoint Sucks!" for reference on "Bad Ideas in SharePoint," let me know.
I didn't get quite as low level as specifying what to avoid because I'm honestly not that experienced with MOSS (versus WSS) and Silverlight. I think an effective talk on what to avoid in SharePoint has to float between the manager, architect, and developer levels--especially since a huge portion of using it effectively is controlling growth and adequately planning for it. Not the sort of thing most developers may care about, but then, it's also an explanation of why things sometimes go horribly wrong.
That sort of topic also requires an audience that is familiar with SharePoint (this was a .NET user group meeting, so the level of SharePoint experience varies). What I may do is prepare, in essence, two presentations--one over the basics, and then one fleshing out this sort of thing. That way, I can switch to whichever is most appropriate for the audience. (So instead of the extremes of "SharePoint Sucks!" or "Intro to WSS3," I could do something like "SharePoint for Developers Who Hate SharePoint.")
Priority one is to find out if some SharePoint feature solves your problem, before you code something up.
Good point. I actually look at this issue from the alternate perspective--if you have to write code, you better take another look at using SharePoint. Effectively, efficiently, and reliably extending SharePoint requires that you have a programmer on staff that spends much of their time working with SharePoint, because it has such a learning curve. If you decide to use SharePoint but code up "just this one thing," you're setting up the potential for a maintenance nightmare.
What are you using instead of VSeWSS? I've been using WSPBuilder--between the templates, built-in build/deploy/debug commands, and manifest.xml generation, it's the easiest thing I've found so far.
I didn't get quite as low level as specifying what to avoid because I'm honestly not that experienced with MOSS (versus WSS) and Silverlight. I think an effective talk on what to avoid in SharePoint has to float between the manager, architect, and developer levels--especially since a huge portion of using it effectively is controlling growth and adequately planning for it. Not the sort of thing most developers may care about, but then, it's also an explanation of why things sometimes go horribly wrong.
That sort of topic also requires an audience that is familiar with SharePoint (this was a .NET user group meeting, so the level of SharePoint experience varies). What I may do is prepare, in essence, two presentations--one over the basics, and then one fleshing out this sort of thing. That way, I can switch to whichever is most appropriate for the audience. (So instead of the extremes of "SharePoint Sucks!" or "Intro to WSS3," I could do something like "SharePoint for Developers Who Hate SharePoint.")
Priority one is to find out if some SharePoint feature solves your problem, before you code something up.
Good point. I actually look at this issue from the alternate perspective--if you have to write code, you better take another look at using SharePoint. Effectively, efficiently, and reliably extending SharePoint requires that you have a programmer on staff that spends much of their time working with SharePoint, because it has such a learning curve. If you decide to use SharePoint but code up "just this one thing," you're setting up the potential for a maintenance nightmare.
What are you using instead of VSeWSS? I've been using WSPBuilder--between the templates, built-in build/deploy/debug commands, and manifest.xml generation, it's the easiest thing I've found so far.
WSPBuilder
I use WSPBuilder, actually my last project just used the command-line WSPBuilder.exe, and I'm experimenting with other options. I haven't used the templates but I'm going to force myself to do so next time around.
Re: the original topic, I think it's interesting to point out that books only have enough time to tell you what each feature does (and generally also can't cover the 'what' completely). This leaves no room for telling you what's a bad idea in SharePoint, or what's painful. I think there's a moment when each person, when they approach their first SharePoint project, wonder to themselves: "am I incompetent?" Because it feels that way. Nothing works, you can't even get your, oh let's say Visual Studio Workflow solution--you can't get it to run at all. And you think to yourself "am I just really bad at this?" And the problem is, because no one is publicly discussing how painful Visual Studio Workflow is, for example, they'll just wonder, and not know.
So for the record, no, it's not just you. SharePoint's Visual Studio Workflow projects are really difficult to work with.
There's also an antipattern I've recognized, which is the "6 week InfoPath engagement." I work for a consulting company and have friends who work for other consulting companies, and this sort of thing is widespread. The deal is, someone else (not the poor implementer) negotiates a fixed-price 6 week InfoPath project. On day 1, the implementer arrives; they are totally new at InfoPath. So when someone asks them to implement a complex business app entirely in an InfoPath form, they don't know--they don't know!--that InfoPath should not be used for that. So they go along with it, and the project is already doomed. Or, if they're clever, they learn enough to find out that you can write code and deploy them with your form, and what they end up doing is implementing a complex business application/process in the code, which so happens to have an InfoPath front-end. In other words, an ugly abberration that should be destroyed.
I'll end this before I go too long. The summary is, NO ONE is an expert at SharePoint, even many of the MVPs. Even those who are recognized as experts are the same as you and me on most projects--they haven't had to do that specific thing before. If you haven't implemented Enterprise Search, then you're not an expert at that. If you haven't implemented forms-based authentication, not an expert. It takes a very rare job description for someone to be able to grab enough expertise at everything. Even full-time SharePoint consultants hopping from client to client--still not an expert.
So don't feel bad that you're not an expert. No one is. My theory is, I'll just throw my opinion out there, and wait and see if someone (e.g. an expert) contradicts me. So far, so good (it also helps that I never update my blog :) )
Re: the original topic, I think it's interesting to point out that books only have enough time to tell you what each feature does (and generally also can't cover the 'what' completely). This leaves no room for telling you what's a bad idea in SharePoint, or what's painful. I think there's a moment when each person, when they approach their first SharePoint project, wonder to themselves: "am I incompetent?" Because it feels that way. Nothing works, you can't even get your, oh let's say Visual Studio Workflow solution--you can't get it to run at all. And you think to yourself "am I just really bad at this?" And the problem is, because no one is publicly discussing how painful Visual Studio Workflow is, for example, they'll just wonder, and not know.
So for the record, no, it's not just you. SharePoint's Visual Studio Workflow projects are really difficult to work with.
There's also an antipattern I've recognized, which is the "6 week InfoPath engagement." I work for a consulting company and have friends who work for other consulting companies, and this sort of thing is widespread. The deal is, someone else (not the poor implementer) negotiates a fixed-price 6 week InfoPath project. On day 1, the implementer arrives; they are totally new at InfoPath. So when someone asks them to implement a complex business app entirely in an InfoPath form, they don't know--they don't know!--that InfoPath should not be used for that. So they go along with it, and the project is already doomed. Or, if they're clever, they learn enough to find out that you can write code and deploy them with your form, and what they end up doing is implementing a complex business application/process in the code, which so happens to have an InfoPath front-end. In other words, an ugly abberration that should be destroyed.
I'll end this before I go too long. The summary is, NO ONE is an expert at SharePoint, even many of the MVPs. Even those who are recognized as experts are the same as you and me on most projects--they haven't had to do that specific thing before. If you haven't implemented Enterprise Search, then you're not an expert at that. If you haven't implemented forms-based authentication, not an expert. It takes a very rare job description for someone to be able to grab enough expertise at everything. Even full-time SharePoint consultants hopping from client to client--still not an expert.
So don't feel bad that you're not an expert. No one is. My theory is, I'll just throw my opinion out there, and wait and see if someone (e.g. an expert) contradicts me. So far, so good (it also helps that I never update my blog :) )
InfoPath, etc.
Thanks for the additional input. This is actually helping me to figure out where to go with my presentation.
I haven't gotten caught in the InfoPath trap, mainly because throughout most of my SharePoint experience (i.e., my last job), I was the only SharePoint guy, and I never saw a reason to go down the InfoPath route. If I ever needed to collect form data, I always had ASP.Net. So I never learned it, which means I never recommended it, which means no one knew about it.
I wasn't saying that I'm inexperienced with SharePoint overall, just MOSS specifically. Most of my experience is on WSS. But I have to agree there's no such thing as a SharePoint expert--or rather, there are multiple types of SharePoint experts. You have to have people who can do the business/analysis/information architecture side, the development side, the systems administration side, and the training/support side. Once you get to a certain point, one person cannot fill all of these roles--SharePoint's complicated, so it's hard to switch from "what do I need to do?" to "how do I need to do it?," even if you have the skills to do more than one of those jobs.
For what it's worth, the "Thinking SharePoint" series on EndUserSharePoint.com addressed this really well, specifically part 2. With SharePoint, you rarely get to the point where you know everything; you just get to the point where you know what you don't know. The problem is that most people stop at that "am I incompetent?" step, or even write it off as "this sucks." But if you know what to avoid doing unless it's a last resort, then it's not so bad.
On that note, I don't even try to read SharePoint books anymore. I can't blame SharePoint, as I rarely stick with reading long enough to finish a book cover-to-cover anyway. But SharePoint's doubly bad as the topics one book has to cover are all over the map--each feature is too small for its own book but too large to cover fully in a chapter. So I've got four SharePoint books that I keep by my desk, and every time I have to do something new, I look up the topic in each one of them.
I've noticed a trend that, to be successful with SharePoint, you have to be a little bit cynical about it to be successful. (Well, successful in the sense of completing a useful project, not successful in the sense of being able to promote it to clients.) Or at least, it's a little more acceptable to be openly cynical about it than it is most other major platforms, technologies, or development methodologies. Or it may all be sampling error on my part--I tend to only listen to technical people who aren't serving any form of Kool-Aid (they'll tell you where the traps are, rather than denying there are any).
FWIW, I was sort of thrown into the world of SharePoint because no other developers where I used to work had time to do it. For the first week or two, I had to talk them down from their initial enthusiasm about it and point out the difficulties. It's sort of ironic that it's become a big a part of my career.
I haven't gotten caught in the InfoPath trap, mainly because throughout most of my SharePoint experience (i.e., my last job), I was the only SharePoint guy, and I never saw a reason to go down the InfoPath route. If I ever needed to collect form data, I always had ASP.Net. So I never learned it, which means I never recommended it, which means no one knew about it.
I wasn't saying that I'm inexperienced with SharePoint overall, just MOSS specifically. Most of my experience is on WSS. But I have to agree there's no such thing as a SharePoint expert--or rather, there are multiple types of SharePoint experts. You have to have people who can do the business/analysis/information architecture side, the development side, the systems administration side, and the training/support side. Once you get to a certain point, one person cannot fill all of these roles--SharePoint's complicated, so it's hard to switch from "what do I need to do?" to "how do I need to do it?," even if you have the skills to do more than one of those jobs.
For what it's worth, the "Thinking SharePoint" series on EndUserSharePoint.com addressed this really well, specifically part 2. With SharePoint, you rarely get to the point where you know everything; you just get to the point where you know what you don't know. The problem is that most people stop at that "am I incompetent?" step, or even write it off as "this sucks." But if you know what to avoid doing unless it's a last resort, then it's not so bad.
On that note, I don't even try to read SharePoint books anymore. I can't blame SharePoint, as I rarely stick with reading long enough to finish a book cover-to-cover anyway. But SharePoint's doubly bad as the topics one book has to cover are all over the map--each feature is too small for its own book but too large to cover fully in a chapter. So I've got four SharePoint books that I keep by my desk, and every time I have to do something new, I look up the topic in each one of them.
I've noticed a trend that, to be successful with SharePoint, you have to be a little bit cynical about it to be successful. (Well, successful in the sense of completing a useful project, not successful in the sense of being able to promote it to clients.) Or at least, it's a little more acceptable to be openly cynical about it than it is most other major platforms, technologies, or development methodologies. Or it may all be sampling error on my part--I tend to only listen to technical people who aren't serving any form of Kool-Aid (they'll tell you where the traps are, rather than denying there are any).
FWIW, I was sort of thrown into the world of SharePoint because no other developers where I used to work had time to do it. For the first week or two, I had to talk them down from their initial enthusiasm about it and point out the difficulties. It's sort of ironic that it's become a big a part of my career.
Post a Comment
To post a comment to this blog entry, login below: