Tuesday, September 23, 2008 3:10:01 AM UTC 

Summary first, because I just re-read this and it's ridiculous long

If you've subscribed to my blog exclusively for the SharePoint bits, sorry; now is the time to unsubscribe.

That goes for both of you/half my subscriber base :)

I've become increasingly frustrated with SharePoint (I'll explain why in, um, detailed fashion), and instead of souring like a lemon, I'm just going to refocus. This means I'm dropping out of the SharePoint blogosphere to focus on long-term fundamentals; knowledge that won't expire when SharePoint 14 hits beta. I may jump back on for SharePoint 14, but it all depends.

Introduction

I've become increasingly frustrated with SharePoint recently (again, I know), but what's been bugging me lately is the fact that I'm solving all the wrong technical challenges. I think I have an (deeply suppressed) aesthetic sense, that every so often, rears its ugly head. Or flares out from my neck like a humongous goiter. Goiters are a serious problem—hey!—used iodized salt, it's that easy.

I get agitated at times staring at (undocumented) CAML, or anytime I work with InfoPath, or remembering when to surround hardcoded GUIDs with curly braces (and when not), or knowing when to dispose SharePoint-created objects, or remembering which Workflow activities only work in SharePoint Designer and not Visual Studio, or working around concurrency bugs, or troubleshooting failed Solution deployments. And so on, pick your topic; these are real issues by the way.

So what's the point of this post again?

I want to send the message out there to everyone working with SharePoint, to look beyond your immediate technical challenge, and think. Think beyond your immediate issue, beyond with what you're wrestling at this particular moment, beyond the immediate (sometimes overwhelming) technical challenge with me. Are you ready? Looking at the size of this post, maybe not!

Let's DO THIS.

Are you an expert at SharePoint development?

I recently watched Dave Thomas give a talk about developing expertise. It's interesting, go watch it if you have time; he's not making it all up on the spot, he relies on some kind of research. In the talk he does something I like: he categorizes everyone (using the Dreyfus model) somewhere along the expertise scale: Novice, Advanced Beginner, Competent, Proficient, Expert. And gives definitions for all five categories, and gives helpful tips for how to work with people of varying skills. It's not all fluff, go watch it.

Bringing this back to SharePoint: after trolling the entire SharePoint blogosphere for quite a while now, I've come to the conclusion that there are no expert SharePoint developers. I'd go as far as to say that there are very few proficient SharePoint developers, and you probably know all their names (hint: look for "MVP" in title and/or multiple Bentleys in the parking lot).

The rest of us are just struggling. The "everyone's struggling" theme really sunk in recently when I browsed the source code for SharePoint-tagged CodePlex projects. All of them (save one) disposed their objects improperly. Including mine, to be fair, I'm not hating on your free, labor of love project, I'm making a point. The point isn't to hate on your baby, the point is to say that no one is doing SharePoint development properly. Look on CodePlex; you'll see what I mean.

Let that sink in. No one is doing SharePoint development properly. Your team may have tackled all the object disposal issues, but maybe you're ignoring large portions of the framework and (unknowingly) rewriting large portions of it. Maybe you don't bother packing things in Features and Solutions; maybe you spend too much time packing things in Features and Solutions. Maybe you're great at writing Site Definition CAML but haven't gotten the memo that putting everything in your site definition is a bad practice (or the other memo telling you that custom Site Definitions don't upgrade to v14). Maybe you are unknowingly triggering framework bugs that ruin your customers' trust in your solutions. Maybe you write unmaintainable code.

Maybe you don't understand your customer's core problem!

Maybe, in your metaphorical dwarven greed, you've delved too deep into the framework, and unknowingly stirred the framework Balrog. And you don't want to wake the framework Balrog, let me tell you.

I don't know about you, but I'm there—I'm struggling.

Takeaway: just try to be competent

Dave Thomas says in his expertise talk that advanced beginners think they're much further along than they are, and those who are proficient or experts think they're beginners. Let me tell you: as far as SharePoint development skills go, I'm an advanced beginner, bordering on competent. And I mean it—knowing that he says "beginners tend to think they're experts, and experts think they're worse than they are"—with all that said and digested, I still think I'm a beginner (advanced beginner, I'm not a total scrub :) ).

So, and this applies to those of you who are still new to the SharePoint world and/or isolated—it's okay to admit that you're not an expert. If you need an ego boost, go look at CodePlex—you'll certainly learn a great many things from others' code, but you'll also realize that hey, these people don't have it together either!

Becoming a competent SharePoint developer

What I've also begun to realize, is that the more I learn about SharePoint, the less I want to apply it to different scenarios. Where before I used to say "SharePoint Workflow is supposed to be good at solving that problem," now I say "SharePoint Workflow is painful, and for long-term maintainability I'd recommend you manually code up whatever you need, elsewhere." Whereas I used to say "InfoPath is useful for simpler scenarios," now I further limit InfoPath to "end-user tool only; don't you dare use InfoPath's code-behind." I say these with specific scenarios in mind, I have biases, your mileage may vary, all things within reason, etc, but the point I'm making stands—recommending SharePoint less.

Dave Thomas says, again, that as an advanced beginner you believe that nothing works. Unfortunately, every time I encounter a new piece of the SharePoint framework, I'm an advanced beginner. I don't have the opportunity of being the CQWP guy. Today I'm that guy, tomorrow I'm the InfoPath guy, day after I'm the admin, day after I'm the help desk. I'm that guy.

I've been an advanced beginner before. For example, I distinctly remember the first time I tried to do Active Directory scripting with PowerShell. It was painful. But gritting my teeth and working through the pain, I became comfortable with it. And, now that I know my way around, I'm able to do some cool (simple) things with PowerShell and Active Directory.

I've been an advanced beginner elsewhere, and worked through it, and at the end, I became comfortable and began to use the technology comfortably.

What I'm trying to articulate in these long rambling paragraphs, is that as I learn more about SharePoint via experience, I become comfortable with pieces of the framework and trust the framework less. As I learn more, I trust SharePoint less. Today I'm totally comfortable in telling you that InfoPath is absolutely great for simple data entry, for simple review scenarios, but nothing else*. And this isn't just InfoPath. As I work my way around the framework, I am becoming comfortable, and as I do so, I am trusting it less.

And let me set the record straight—I'm less interested in whether a particular technology is Turing-complete, which means it can theoretically solve any problem—I'm more interested in whether using that technology is a good idea in the first place. And as I learn more about SharePoint, the world of good ideas seems to shrink.
*note for InfoPath nitpickers: yes, it's useful for other things, but yes, it's also easier for me to say "good for nothing else" than rattle off 15 edge cases.

Do you want to become proficient?

I think what is bugging me most is that I don't want to be a SharePoint apologizer. Not apologist, apologizer.

Oh, sorry, that doesn't work. Sorry, yeah, there's a bug. No, yeah, you heard it was great for ECM; well, yeah, it's cheaper, but we'll have to customize a lot. Oh, yeah, that's undocumented. Oh, no, we hit the list size limit early. Yeah, no, SharePoint Designer is unmaintainable, don't use it. Oh yeah, factor in cost of upgrades on every SharePoint project.

Last week we found out "the hard way" that SharePoint can't handle 12000 documents in a single folder, no metadata, no versioning, nothing fancy. Performance whitepaper aside, 12000 documents shouldn't be a problem, I don't want to hear about it—this is a bug. And meanwhile, from the other end I'm attempting to fend off a total migration of terabytes of network file shares to SharePoint, because "this should work, right?"

I don't want to progress with SharePoint, if my energy is going to be spent hurdling the wrong challenges.

Add in the cost of learning

Something that I'm maybe not emphasizing well enough is the fact that in theory, all things are possible in SharePoint. And if the cost of becoming a SharePoint expert was zero, it would worlds better than coding by hand. No contest, no question, better.

But learning is not free.

SharePoint gold rush

Dux Sy refers to a SharePoint gold rush. It's real. It's real in part because the time cost of learning SharePoint is so high. Chris O'Brien (I can't find the entry on his blog) states that you should be wary of hiring SharePoint developers with less than 10 SharePoint projects under their belt. It's expensive to find people with that kind of SharePoint experience. Thus, high prices, thus, gold rush.

This equation works for all Enterprise solutions; when I talk about how SharePoint is aggravating my inner engineering brain, trust me, I've worked with other Enterprise systems, and they're worse. SharePoint's a great "Enterprise" product—believe it or not, Microsoft is quite open compared to other vendors, who require all independent consultants be licensed by the vendor, or who provide no public documentation at all—artificially inflating consulting prices. So, it could be worse.

No more SharePoint on my blog

I've posted exclusively SharePoint content for a while now, and as I do so, I notice my attitude continues to trend negative. It's my doom-and-gloom engineering brain, it can't just let it go. So, instead of ranting further, I'll just, hmm, let it go. No more SharePoint 2007-related topics on my blog, even if a potential topic is brilliant (WHICH IT INEVITABLY WOULD BE!). No more SharePoint content unless I just can't hold it in.

If you've subscribed to my blog exclusively for the SharePoint bits, sorry; now is the time to unsubscribe.

I'm also officially done learning SharePoint 2007 development, permanently—no more off-hours learning, no more digging through my humongous SharePoint blogroll. When SharePoint 14 is announced, I'll evaluate it to see if they've fixed anything—to see if the situation's improved any. If so, great! Maybe SharePoint 14 will realize the potential of what some are calling "the first real application development platform from Microsoft." There are some awesome business problems that SharePoint already attempts to solve—that with just a little extra help, could be seriously powerful. SharePoint could be dominant, even.

But if SharePoint 14 is more of the same; if they announce SharePoint Designer Designer 2009, and we're all given the "look what you can do without coding!" demos, and the BDC is still 14 pages of XML without proper tooling, and SharePoint still produces noncompliant HTML out of the box, and I'm still handwriting Feature manifests, and I'm still handwriting CAML, and I'm staring at a doubly-XML-encoded internal field name passed as an argument to a custom XSL function emitting HTML and all this is wrapped in a XML-encoded WebPart tag, and a new SPDataGridView is released and it adds 50 more undocumented methods and properties, and we need to rewrite all our SharePoint 2007 customizations just to make them work with v14…well, we'll see. If MSDN rolls out a SharePoint 14 resource center and it has 3 articles and 50000 useless Sandcastle-generated stub pages—gold rush or no—it may be time to bail.

So what are you going to focus on, Peter?

I have three words for you.

FUN.
DUH.
MENTALS!

Project management (not getting a PMI cert; instead, the meat of project management). Proper object-oriented design. Programming languages (plural). HTML/CSS/JavaScript (they're not going anywhere).

Personal projects!

Programming for fun—something that may even inspire me!

And hey, maybe SharePoint 14 will be a pleasure to work with; maybe I'll jump on that bandwagon…I'm the guy who owns sharepoint14.com, after all.

Monday, September 22, 2008 8:00:22 AM UTC 

A while ago I came across a paper written by Niklaus Wirth. Well, okay, I don't read "papers", but I do read programming.reddit.com, and so came across some guy who does read papers, whose story made it to the front page. I'm going to link to him.

I'm only going to quote a small section of the original paper, then ask: does this sound familiar to you in any way?

Okay, here goes:

By contrast, modern languages are constantly growing. Their size and complexity is simply beyond anything that might serve as a logical foundation. In fact, they elude human grasp. Manuals have reached dimensions that effectively discourage any search for enlightenment. As a consequence, programming is not learnt from rules and logical derivations, but rather by trial and error. The glory of interactivity helps.

…so, ring any bells?

Monday, September 22, 2008 8:00:22 AM UTC 

Estimating is difficult to begin with, but add on

• a new technology stack with which you're unfamiliar,
• sometimes unreliable and often undocumented API (I can back this up with examples, just take my word for it),
• tight integration/reliance on Active Directory, SQL Server, IIS, Exchange, Office, and Internet Explorer, all of which may fail in difficult-to-debug ways;

Given all this, how much risk are you taking on if you provide a tight estimate? If you haven't tackled three or more Visual Studio workflow projects, for example, how do you even go about getting a ballpark estimate on your first one?

On a recent project I put a 10x difference between my lowest and highest estimate for an SAP integration task, and everyone complained to me about how "there's too much variance." Well, what should I put there, I've never tried it before!

This isn't a passive-aggressive way of trying to win a work argument via my blog. If I start doing that, dude, let me know, I don't want to be that guy.

But it is a cry for help. How are we supposed to estimate SharePoint development tasks? If you're not an experienced SharePoint team, and by "experienced" I mean experienced in building the exact same solution, using the exact same method calls on the exact same SharePoint objects—if you're not truly experienced, then how do you even attempt it?

When you may be blocked anywhere between zero and ten times on a single task, and each blockage may take up to a full week (or more) to resolve?

When your project approach hits a dead end? A brick wall?

In traditional build-it-from-the-ground-up systems, you can estimate the complexity of your requirements and envision a rough idea of what your solution will look like, and compare the complexity of your new task with similar tasks you've done in the past. This works for traditional development, so long as you double your estimate and increase it by an order of magnitude :). The idea is, when you're building it from the ground up, estimating is "as simple as*" estimating your effort based on the complexity of the problem.

But if your task says "write a custom field that pulls data from SAP," or "let's build our entire app in a Silverlight web part," how do you put down an estimate? When the task, performed by an experienced expert (see above for definition of experienced), takes (for example) one hour, so in reality the bulk of your time is spent discovering how to do that one hour task?

What do you do when your honest estimate is, "this will take between 4 and 400 hours?"

I don't have the answer

I'm just throwing this out there because no one even talks about it. So here it is. When you're on a project and someone asks you for an estimate, and you answer "4 to 160 hours", and they laugh, hey—you're not alone. I can't figure it out either.

Wednesday, September 17, 2008 8:00:30 AM UTC 

I've been fascinated with learning as much as I can about SharePoint 14, also known as "the next version of SharePoint." You can see the list of everything I can find publicly here: http://www.pseale.com/blog/SharePoint14EverythingWeKnow.aspx (nothing much has changed since I wrote that post).

One of the advantages of picking up these little tidbits (as well as reading every SharePoint blog known to mankind) is that you can make better guesses.

So, what follows are my educated guesses as to what technologies we'll be adding to the SharePoint arena, with the idea that you can brush up on some of them in preparation. Or just get depressed. I'll help speed the process, either way.

Technologies we'll see in v14

PowerShell

I've seen a hint dropped (by a MS employee) that PowerShell will be part of the next SharePoint framework. I'm guessing admin-style cmdlets, maybe better wrappers than using stsadm. I've become accustomed to using stsadm, but could definitely use some PowerShell shortcuts, especially if they could balloon the number of things PowerShell exposes. There's a lot of potential for using PowerShell as an admin interface, way more than even Exchange 2007 is realizing. And all this on top of everything PowerShell gives you today.

Anyway, learn PowerShell! It's going to be the easiest thing to learn, by far, and as I tell everyone, PowerShell is one of the few technologies that has saved me time, even including the time spent to learn it.

Windows Communication Foundation - WCF

It's inevitable that SharePoint will expose WCF services, and even if SharePoint doesn't, then we'll still eventually be writing our services in WCF (as opposed to ASMX web methods). So, learn the ABC's of WCF. Sahil Malik covers WCF for SharePoint 2007 on his blog, so maybe that's a good place for you to start.

We can hope for WCF services that replace the SharePoint built-in web services of today, though I honestly don't know how they'd improve. Maybe they'd be able to generate list-specific services? I.e. instead of a big "GetListItems" that takes the equivalent of a SQL SELECT query, they'll have something more context-specific? We can hope.

Silverlight 2.0

I'm not sure what form this will take; at minimum we'll have Silverlight Web Part templates. We can also maybe get some "all-Silverlight" site templates, where you visit the site and you don't see a single bit of HTML. As far as I'm concerned, Silverlight looks like a more difficult way to do the same thing we're already doing, but hey, that's me, I'm cranky. I'm going to skip this whole Silverlight thing until someone proves that it's easier to work with Silverlight than the equivalent solution using HTML/CSS/JavaScript; I'll re-evaluate periodically. I'm way too overwhelmed with learning to take Silverlight seriously, so don't expect me to jump on this bandwagon anytime soon.

It's also possible InfoPath will use Silverlight; think about the possibilities (but as always, don't get carried away :) ).

Also, if you're learning Silverlight, then you'll be learning WCF, gotta talk to the server from your Silverlight client somehow.

Claims-based authentication

This is a big shift and, while it may not happen for SharePoint 14, it is probably worth learning about anyway. Here's the NetworkWorld article from 2007 discussing the possibility.

.NET 3.5, IIS 7, Windows Server 2008

I'm including all these for completeness' sake; duh.

Stuff we haven't heard about yet

This section is also included for completeness. While I don't think v14 will be as big of a shift as 2003->2007 was, what do I know? Maybe the entire Dynamics platform will mash itself inside SharePoint; you can only hope (dread) the possibilities. I'm just saying here that no, I don't know what else we're going to get. I can't imagine what Access Web Access will look like. I don't know how Groove is going to work in the new version (are we going to get offline support out-of-the-box? I don't know). I don't know what the SQL-table-backed-lists will do and how they'll work. I don't know if they'll revamp the BDC. There's lots I don't know.

New slices in the SharePoint pie

Master Data Management (MDM)

This will be big. Read up on MDM. You're not going to be an MDM expert, but at least you'll know that it's not as easy as running UNION queries on disparate data sources. Hopefully that doesn't go into the marketing packet.

FAST search (Enterprise Search revamp)

This will change SharePoint's search engine, maybe not in time for SharePoint 14, but maybe so. Microsoft has proven they are able to do out-of-band improvements on their Search platform (MS Search Server), so even if this doesn't happen in time for RTM, you won't have to wait until v15.

Here's a discussion of the FAST Search acquisition on CMSWatch; you can read elsewhere (MS Enterprise Search team blog) about the acquisition, and of course you can check out FAST's product itself, as it exists in its non-integrated form.

Do you have time to learn all this?

If there's an argument to be made for specialization inside of SharePoint, combining this with the existing SharePoint 2007 architect skillset should do it. Don't even try to stay on top of all this; you can't.

Wednesday, September 10, 2008 2:45:24 AM UTC 

In my learning journey from earlier this week, I forgot to mention something:

Don't dispose SPWeb or SPSite objects you get from the "properties.Feature.Parent" property. This isn't coming from me—I got this information from a good source.

So, here's a little visual guide:

From my brief survey of CodePlex projects, it looks like most people were following this rule anyway.

Tuesday, September 09, 2008 11:02:20 AM UTC 

click for OPML file

Read about Patrick Tisseghem, sad

Tuesday, September 09, 2008 10:29:40 AM UTC 

If any of you out there are looking to find reasons why SharePoint is a "challenging" developer environment, you need look no further than explore the guidance on when to dispose SPWeb and SPSite objects. I was reading Chris O'Brien's blog (which is a veritable font of knowledge on SP dev topics) and found this page, discussing his generic approach to disposing objects, and figured I'd better post this so I can just get it out. Keep in mind folks, that every single SharePoint developer in the world must deal with this issue.

To introduce the problem: Your friendly SharePoint objects SPList and SPWeb will on occasion interact with a COM component. Each pop, for each reference, they hold between 1MB and 2MB of memory. That adds up quick.

So far we're okay, because .NET has a facility for disposing these unmanaged resources (among other things)—through the IDisposable interface. This is why we tell everyone to wrap their code in using blocks—it's to make sure that the unmanaged resources (like the COM components I mention above) are properly released. If you're writing code in SharePoint and you're don't know what a using block is, go read up on it. If you're ignorant of this, it isn't the end of the world for you, but it's close.

Where were we again? Oh yes—SPLists and SPWebs hold unmanaged resources and must be disposed. The "duh" solution is of course, to wrap everything in a using block.

Unfortunately, disposing in SharePoint ain't easy

The first problem you'll run into is when you try and use SPContext.Current.Web - a static getter method. Do you dispose the SPWeb object here, or not? Note that if you dispose an object that's in use elsewhere, you'll cause new problems! Problems you didn't forsee!

This is starting to feel like whack-a-mole. Whack the unmanaged resource mole, up pops the "you whacked the wrong mole" mole.

Whack the "you whacked the wrong mole" mole

So now we know, okay, dispose SPWeb and SPSite objects, but don't dispose the SPContext.Current.Web object. Okay, two things to remember, I can handle that. Unfortunately, we're not done—we're not even close to done. We still have to deal with the "SPList.Web" reference mole, "SPSite.RootWeb" reference mole, the "enumerating through a collection" mole, the "I didn't use the unmanaged resources, this time, and thus don't really need to dispose" mole, and so on.

Disposal strategy Whack-a-mole

There are a bunch of resources you can read on this topic, including:

• Best Practices: Using Disposable Windows SharePoint Services Objects [on MSDN] - good introduction to the topic, but not comprehensive - thanks Jeremy for the link
• Roger Lamb's [MS employee's] nearly-comprehensive list of dispose patterns by example
• Disposing SharePoint objects - what they don't tell you by Chris O'Brien [MVP], as linked above
• Keith Dahlby has posted several times about this:
  • http://solutionizing.net/2008/07/23/spsite-spweb-leaks-revisited/
  • http://solutionizing.net/2008/08/10/is-splistparentweb-a-leak/
• …probably lots of others I haven't referenced

I'm still playing whack-a-mole, but I'm holding steady at the "apathetic about which mole to whack because there are too many moles to keep track of" mole. Oops, sorry, "apathetic about which mole to whack because there are too many moles of which to keep track—there, now I'm not ending my sentence with a preposition" mole.

I'm probably stretching the whack-a-mole reference too far

If I've lost you in the craziness above, let me just summarize by saying: a) object disposal in SharePoint isn't simple, b) I've given up looking for the "perfect solution".

Let's tackle my less-than-perfect solution for object disposal next.

Peter's (newer—thanks Keith) imperfect strategy

Let me first say that I wrote up "my current technique" in this post and secretly published it to my blog. Unfortunately (or fortunately) "secretly publish" doesn't work as well as it should and I got comments. My original approach, which was my firm stance as of Sunday, has changed quite a bit, it's been a full 24 hours. I've taken a little learning journey in the comments below, and in a post on the MSDN forums, where I got an authoritative answer within an hour. Nice!

So, anyway. My newer strategy is to basically copy either Chris O'Brien's or Keith Dahlby's approach, with the one extra little tidbit thrown in: if I'm unsure whether or not to dispose an SPWeb object, I will gather the minimal information necessary from this SPWeb object (e.g. RelativeUrl, Id property), and spawn a second SPWeb object, which I am safe to dispose.

Here's the full algorithm that I use to guarantee I'm safe:

• Follow published guidance to figure out whether the method call/property getter I'm using will produce a safely-disposable SPWeb or not. This applies really to any IDisposable SharePoint object, including SPSite, PublishingWeb(?), Area(?), and objects of which I've never heard. For this example, SPWeb.
• If definitely yes,
  • Great! Enclose in a using block.
• If we're unsure for any reason,
• Use the SPWeb object we're given, and somehow, with the lightest footprint possible, create ourselves a second SPWeb object, that we're guaranteed we can dispose!
• We can use this "spWeb2" object and proceed along our merry way, disposing it with glee!
• If definitely no,
• Great! Don't dispose it!

Tear it up

Feel free to tear this approach up (assuming I or someone else hasn't already done so). I can take it.

Tuesday, September 09, 2008 8:00:17 AM UTC 

I recently read Matt Blodgett's post called SharePoint is the Future of Microsoft-centric Application Development, which is interesting because there's a grain of truth in what he says (not more than a grain though :) ). I want to focus today on the following quote:

[…referring to SharePoint projects] Clients are amazed when they see 80% of their app done in a week. What they don't see until later is the weeks/months of excruciating work it then takes us to crowbar the remaining 20% into an ill suited platform.

Ok. I'm only using Matt's sentence as an example because I hear it everywhere (and have probably said it myself several times before). It's completely correct; you want to try and solve the customer's core problem, something SharePoint's out-of-the-box features are good at doing quickly.

But, I need to elaborate. Something I'm not sure everyone is getting, is the corollary:

Lesson: You can stop after the easy part!

You can stop at 80%! This sounds obvious to me, but maybe someone out there hasn't had their eureka moment. "Now wait a minute," I hear you telling me, "we need all of this to work, not just the easy parts!" Okay, let me tell you a story.

Story time!

Earlier this year, I was asked to estimate how long it would take to build an employee vacation scheduling solution in SharePoint. As I dug into the problem, the complexity jumped out at me. We were going to pull some data from the ERP system, run a gauntlet of vacation prioritization, and even include a period of "open enrollment" wherein employees' requests would be put in a prioritized queue. And write something back to the ERP system. And supply complex reports. And so on; it was clearly not something we'd be able to solve with out-of-the-box features and would take a while.

After asking the client about cutting bits from the app, they explained that they couldn't cut features; we'd have to do it all.

So, we had a relatively complex app to build, and limited leeway. What were we to do?

In the end, the client and we agreed on not implementing this as a SharePoint solution. We parted ways, so to speak.

Now, you may ask yourself, where was the "80%, then stop" in this story? I did say, after all, that they didn't pick SharePoint for the app, right? Right.

What I didn't tell you is that SharePoint was already running their vacation scheduling; it was doing the 80% of what they needed, and they came to us asking for the remaining 20%. Because SharePoint was not the most efficient way to solve this complex problem, and because there were no outside extra benefits to using SharePoint, there was no point in implementing the solution in SharePoint.

Lesson learned: wait, what was the lesson again?

Ok, here goes:

Lesson: You don't have to use SharePoint!

You can develop apps outside of SharePoint! I'm sorry I typed this up; it's too obvious. Let's take a more helpful approach, something you can use:

Lesson: Know 'why' you're choosing SharePoint as your platform.

Even if you need to run your app in SharePoint, so to speak, what specifically do you need to run in SharePoint itself? Do you need to store your data in custom lists? Do you need to run all on the same physical web server? …now are you sure about that?

I was inspired when I saw kroger.com, which is a public SharePoint site by the way, and how it handles integration—while the look-and-feel is all the same, it's clear that they're only using SharePoint for its publishing features, and "going elsewhere" for any of their complex needs. They don't even try to get everything onto the www.kroger.com domain; if you look carefully you'll see you're being redirected to different servers. Which is fine. If "allowing us to run multiple domains" cuts costs by 80%…

Personal bias

I have not worked on any sort of ECM or huge portal project. If I had, I might have had a different opinion; in those cases, you may "need" to have everything run in SharePoint; maybe the data's stored in SharePoint document libraries, or maybe you need need everything to run on your portal. But as I mentioned above—if you don't know why you need it to run in SharePoint—then maybe you don't need it after all!

Sunday, September 07, 2008 4:44:06 AM UTC 

In a previous post, called Thinking Creatively, I asserted that in SharePoint, "we are forced to think creatively" in crafting solutions. Like when someone asks you to create a custom web part on the intranet home page to do employee search in SharePoint, you are supposed to say "hey, aren't you really asking for People Search?" And the idea is that you would then work with your customer to find the real solution to their problem, not just blindly follow directions. Maybe People Search works for them, maybe you end up writing a custom web part or configuring SharePoint's search. You solve the real problem.

Well, I was wrong.

If you remember to do so, you'll think "out of the box" in  "dynamic way" and "harness the synergies" et al, as mentioned in the scenario above. But if you forget, if you slip up, guess what?

Or what happens if your client is belligerent and wants it done their way? FYI for everyone who knows me, I'm not saying this is my client :), but have instead heard secondhand about these situations.

Bad times.

In Summary

Remember to argue with your customer! This is a fundamental aspect of any project, whether it's SharePoint or not—it just happens to sting more (a lot more) in SharePoint when you're forced to follow strict requirements.

I'm not saying you should add a "fistfight" bullet point to your next customer meeting agenda—or maybe that's not such a bad idea after all! Treat your meeting like a boxing match: instead of doing bullet points, say "ROUND 1: do we really need to brand SharePoint?" and "ROUND 2: Can we change the way this app "runs in SharePoint"?" Set the Outlook meeting location to be "THE OCTAGON". Bring a metal folding chair and lean it next to the door, in case someone needs some extra "chair therapy" across the back. Go wild, it's your meeting.

Tuesday, August 19, 2008 8:00:31 AM UTC 

One of my friends is starting his first SharePoint project, and I had a few words of advice for him. He doesn't know exactly what his project entails, I don't know what his project entails, but we will start with the following assumption:

The following advice assumes that we are working on a small-to-medium sized, line-of-business application, possibly something attached to a traditional portal (i.e. intranet). We are not working on a BI project, not rolling out an entire enterprise intranet, not creating a publishing site (WCM), not even doing formal records management.

First tip: Read this other guy's post on the subject

I found an excellent post by Mark Jones written mid-2007, which is ancient history in SharePoint terms. If you can't be bothered to read both his post and mine, choose his: Mark Jones on SharePoint projects (original post disappeared, this is a link to the post in my Google Reader)

Second tip: Use either WSPBuilder or STSDEV in Visual Studio

It is well known that no one really uses the Microsoft-created Visual Studio Extensions for Windows SharePoint Services (VSeWSS). Well, no, if everyone already knew, then I wouldn't be writing here, would I now?

So let's start with a fresh mind. You're new to SharePoint, and you need to do … something, let's say change the PDF icon that appears in document libraries on your SharePoint farm. Terrible example, I know!

I'll assume you have rudimentary knowledge of SharePoint's Solutions and SharePoint's Features. If not, read up on it, there are intro books and articles out the wazoo. I'm not going to into depth here; read up on Solutions and Features elsewhere.

Moving along.

So you fire up Visual Studio. You've already installed VSeWSS, and now you've got this "SharePoint" tab in Visual Studio, and you click on it.

I'm not here to only throw rocks; I'm here to say that, unless you want to endure a great deal of pain, don't stick with only VSeWSS.

You have alternatives:

• WSPBuilder via the WSPBuilder extensions
• STSDEV
• "Naked" class library project with WSPBuilder as a post-build task
• "Naked" class library project with MAKECAB (!!!) as a post-build task/MSBuild task

To the initiate, to the untrained eye, these are all equally good options. They're not. Let's work through the list again, this time with a critical eye:

VSeWSS - Visual Studio Extensions for Windows SharePoint Services 1.2

You're going to have to install this as it is the easiest way to get the SharePoint-specific Workflow activities. Otherwise, don't use it. Search for others' complaints about VSeWSS; general consensus is that it's okay, but painful.

STSDEV - a proof-of-concept utility

Link to STSDev project home 

Contrary to the aggravating unnecessary disclaimer prominently displayed on the CodePlex project home page, STSDEV can be useful in actual, real-life projects! Shh, don't tell anyone, they might figure it out!

Aside from my nitpicking, this is a good tool.

• Generates the Solution manifest.xml for you, for limited scenarios
  • In fact, generates an entire project skeleton. This includes the feature.xml manifest, something for which you'll be thankful if you're learning the ropes.
• Builds your Feature event receivers for you
• Screencasts on how to use it! Ted Pattison is an excellent communicator and presents three screencasts, available from the 1.2 (previous release) page on CodePlex.
• In other words, STSDev is a good way to start off a new project, assuming it has a template for the thing you're trying to build. I don't use this as I've pretty much settled with WSPBuilder, but acknowledge it's a good solution, and will definitely use it in the future if I find STSDev has something WSPBuilder lacks.

WSPBuilder extensions

Link to WSPBuilder project home

The WSPBuilder Extensions are relatively new—they add Visual Studio project templates, quick shortcuts, and WSPBuilder-specific item types. LIke the WSPBuilder command-line tool, the WSPBuilder Extensions also completely eliminate the pain of Solution packaging.

• WSPBuilder project template is a real, new Visual Studio project template. It saves you the trouble of manually configuring your Visual Studio project to work with SharePoint; stuff like making a .snk file, adding a "Build WSP/deploy/upgrade/uninstall" option to your project (further note: uses SharePoint object model directly for faster performance); and other little bonuses (see screenshot above).
• Downside: Unlike STSDev, you're locked into WSPBuilder Extensions once you start using the Project Template. I'm not worried, because I would feel comfortable switching the project over to a raw class library, but you may be allergic to dependencies like this.
• New Item templates (like "Web Service") - I haven't tried these, nor have I heard reports of how well they work; so I'll just say—try them out, if they work for you, great; if not, definitely don't use them.
• Assuming you arrange your artifacts in the correct directory structure, WSPBuilder will eliminate the pain of building Solutions. See my review of WSPBuidler.exe below for more details on what this does.

WSPBuilder.exe - command-line tool only

Link to WSPBuilder project home

In ye olde days, as far back as almost a full year ago, we were not blessed with either STSDev or WSPBuilder Extensions. We made do with what we had; WSPBuilder.exe.

WSPBuilder.exe is great because it is focused: it does one thing, and it does it very well. What is that one thing, you may ask?

It eliminates the pain of Solution packaging. That's all it does. To be honest, I don't even know how to build a Solution manifest XML file, and I attribute my brazen, unashamed ignorance to WSPBuilder. I don't need to know because WSPBuilder takes care of that for me.

The pain begins, however, with the rest of your project. WSPBuilder Extensions address some of this pain, and I recommend you start with WSPBuilder Extensions for new projects, but you'll find many projects that were started during the "WSPBuilder-only" era. Don't make fun of these old projects; we can only hope someday that we will be able to look back and say "what primitive tooling we had in 2008!" Just like you're wont to do when you see a project that uses WSPBuilder.exe or MAKECAB.exe to build its Solutions. We can only hope the tooling improves.

If you want to see a simple example of how to work WSPBuilder.exe into your Visual studio project, I demonstrate one way of doing this in my terrible CodePlex project. F5 is my build, and I'm (almost) unashamed!

Raw MAKECAB.EXE

This seems to be the preferred method for the "old school" SharePoint experts who have been around. I assume that, for them, they have learned how to use MAKECAB.exe and build their own Solution manifests. Ugh. Ultimately if you know what you're doing, this is as good as any other way, but for the first-time SharePoint developer, this isn't a good option. I want to point out MAKECAB's existence because the MSDN-sponsored articles and project templates all rely on MAKECAB.EXE. You don't have to listen to those articles; save yourself some pain and pick something else. There are far better alternatives to hand-crafting your own Diamond Directive Files and hand-crafting your own Solution manifests. Look around; better ways of doing this exist!

Recap

Both WSPBuilder Extensionss and STSDev are good solutions for the budding SharePoint developer; they both provide some tools to help you create and build SharePoint projects in Visual Studio. They are in no way complete tooling; you will still experience pain, but they both help greatly. Try both out, choose one and go.

Just don't stick with only VSeWSS or only MAKECAB; save yourself some pain and choose one of the alternatives.

MORE TO COME!

This post has gotten ridiculously long, and I barely just compared the major competing developer tools! We're nowhere close to done; more posts to follow on this subject.

Monday, August 18, 2008 8:00:15 AM UTC 

When converting an existing "please leave us a comment" form, I had a eureka moment: SharePoint's user profiles are incredibly useful. Let's do this graphically:

Before - ask the user, again and again

After - SharePoint stores user data automatically in the "Created" field

Well, you get the idea anyway

The point of this exercise is to show the power of integration. Specifically, user data like phone, email, work location, department, etc. In an ideal world, SharePoint will pull this data for you from wherever it's stored. HR type data from the HR/payroll system, email from Exchange/AD, and so on. With proper integration you can remove all the pain of online forms; you can completely remove the five "who are you again? and what do you do again? and how do I get a hold of you again?" fields. They're gone; thanks to proper system integration, you already know and don't need to ask these questions again.

Footnote: it's not all gravy

I must acknowledge that there is no easy way to grab and show all this extra data from the user profile without writing code. I wish SharePoint would have made this easier, but alas, 'twas not to be. In the browser, you can certainly click through to see their user profile data, which is good enough for the example above, but that won't always suffice.

Second footnote: user profiles in all their glory require MOSS Standard or better; this is not a WSS-only feature.

Sunday, July 13, 2008 4:50:49 AM UTC 

Ok, so I'm burned out.

I realized this while digging through my queue of SharePoint-related blog posts. I wasn't reading all the technical bits (which is normal), but I realized I didn't even want to know what any of the blog posts were about. This antipathy is new.

But I'm not writing here, today, just to tell you I'm burned out. I'm going to hit a few topics and hopefully draw them all together at the end. Maybe by the end we'll figure out why I'm so burned out. Let's do this.

Do you have time to learn everything?

I came across a post (via DotNetKicks) asking if we have enough time to learn everything in the Microsoft stack. It's an interesting question, and always leads to good conversation. "How do you keep up?" is a fun question to ask.

Unfortunately the author, in what has to be a misguided set of priorities, has chosen to devote all his learning efforts to LINQ to SQL and the Entity Framework. Which is a ridiculously bad idea. Don't worry, I told him the same thing in the comments, I'm not just sniping from afar.

What bugs me about this idea is that it's almost the exact opposite of my learning priorities. LINQ to SQL and the Entity Framework are almost dead last on my list—how did he end up choosing these two volatile technologies over everything else?

Think about that for a second. How did he arrive at the misguided conclusion that learning these two things was a good idea?

If you're interested in my specific critiques, they're all in my comment on his page; I won't repost them here.

When doing research, always consider the source

I also came across a discussion started by Andrew Connell on how CMSWatch is biased against SharePoint.

If you're unaware, CMSWatch is a site that sells a $1450 SharePoint report that critiques SharePoint in a variety of categories, as well as provides advice. Andrew Connell is an MVP and is a known authority on SharePoint WCM and developer topics.

AC's point was that not only is CMSWatch biased, but they've also caused him extra trouble in the past—he explained that he had to 'clean up' after them—where he has had to expend extra effort convincing clients that SharePoint can properly do WCM. People who haven't been 'poisoned' by CMSWatch don't require this extra effort.

My comment to him (poorly worded and not in total disagreement) is that I'd rather have CMSWatch and their criticisms of SharePoint than not—I'd rather "clean up" by convincing clients that SharePoint can work, rather than "clean up" by convincing clients that SharePoint isn't the 'everything solution.'

I'm not here to weigh in on the actual discussion of whether CMSWatch is biased or not; I don't know, I haven't seen the report. I will say that this summary written by one of the principals is unfair (go see the 'Ugly' section), but for the most part I'll stay out of it. I don't know.

Instead, the question is: why do I encounter SharePoint overexuberance more often than SharePoint skepticism?

Oren Eine at the Future of .NET Panel on DotNetRocks

A while ago I listened to a podcast, probably my favorite DotNetRocks episode of all time: DotNetRocks Show #346: The Future of .NET Panel. Even if you're totally bored by me, go check out the site and download the podcast, it's a fascinating (and you'll be happy to hear, civil :) ) discussion of .NET development in general.

The thing that really got me going is at ~1:06:00 into the podcast, when Oren Eine describes a challenged deployment of MS CRM customizations:

Question here: why did Oren's story strike such a chord with me? He wasn't talking about SharePoint at all!

Do Less. Get More. Develop On SharePoint. - www.mssharepointdeveloper.com

Also launched sometime recently is the SharePoint Developer introduction for .NET developers. Instead of writing, I'll express myself by defacing a screenshot of the front page of the site:

The question for you, dear reader, is why am I so virulently opposed to including Silverlight in the list above? It's the future, right?

And what's the deal with the Entity Framework vote of no confidence?

This is way too big a topic to cover properly; I'll just assume you know what I'm talking about and skip straight to my leading question.

Why does anyone care if the Entity Framework is released as-is or not? What difference does it make to them; they can just use something else to do data access! Why can't they just live and let live?

"SharePoint is a guild", by Tony Byrne

I also recently attended a presentation by Tony Byrne (from CMSWatch, yes, see section above). I've covered the session in more detail here, if you're interested; the quick summary is that he was providing a quick critical review of SharePoint, a sort of summary of their report. One statement that caught my attention was that he likened SharePoint to a guild. I don't recommend you take this metaphor too far, I'm not a medieval scholar and I don't think he is either—but the idea is that there are a select chosen few who are in the "guild" and have collected secret, arcane knowledge. Those outside the "guild" are not privy to the same knowledge and benefits of those in the "guild".

We could have a very long and unproductive conversation about this, there's several ways to go with it. But why does this crazy idea of a SharePoint "guild" have any merit at all?

Ok, let's pull all this together

We've wandered far and wide today. We've talked about some random guy's technical learning queue; we've discussed the impartiality of CMSWatch; we've heard a story of a painful MS CRM deployment; I've defaced a screenshot; we've approached the topic of the Entity Framework before running away; and finally, we've talked about medieval guilds.

Where does all this relate again?

Ok, I'll try to boil this down. [re-reading the section below, it appears that I failed to 'boil it down'. Too bad; we're stuck with it. -ed]

Overexuberance, belief that improvement is inevitable

What I experience on a regular basis is an overexuberance, a faith in the current crop of Microsoft's technology, as well as the common belief that future improvements are inevitable. In reality, however, no technology is perfect, and many improvements perceived as inevitabilities will not materialize.

Some of this overexuberance is the result of aggressive marketing. But I'm starting to realize as well—we're duping ourselves. We don't even need marketing to tell us that, say, Silverlight is going to be 'the best development toolset provided for the web'—no need for marketing, we'll do that all by ourselves!

We believe that SharePoint's WCM featureset will improve, without any evidence or indication from Microsoft that this is the case! Will SharePoint 14's HTML be accessible out of the box? Are you sure about that? Who told you that? No one?

Learning investments with limited time

What seems to be completely ignored by Microsoft is the hidden cost of learning—for each technology or framework or product released, there's an associated cost. Learning is the number one cost of introducing any new technology!

So why is it then, if our attention is so valuable, that when we are presented with the foundations of SharePoint development, we see Silverlight in the list? Not only is Silverlight completely useless to me for SharePoint development today, 2008-07-12 (note I timestamped this assertion), but it's probably actively worse than the competing technologies (which are some combination of InfoPath, HTML, and/or something "not in SharePoint at all")? Microsoft, instead of attempting to ease my learning burden, sneaked in the additional burden of Silverlight…which is useless!

Now hey, I hear what you're saying: so what if they threw a little marketing in there? You can just ignore it, right?  I can. You can. But what about the guy who has heard about this "SharePoint" stuff, and has also seen something about "Silverlight", and hey, look at the website! It says you can make these two things work together! Sounds easy!

Now fast forward a bit. When this poor guy can't deliver, whose fault is it? Sure it's his fault, somewhat. But is it his fault he was distracted for 3 weeks trying to get his Silverlight applet working in a SharePoint farm?

So is this why everyone's so excitable about the Entity Framework? Because it will make their jobs harder in the years to come—not easier?

Now let's hop back to SharePoint's WCM again, but this time, in the context of learning. If you installed the product sometime in 2007 and discovered a) emitted HTML was not accessible, b) branding was difficult, c) content deployment jobs failed often (hopefully you catch this one before go-live!), then were you supposed to think? Sure, if you knew all the right things, you could work around the problem. But what if you didn't? Is it your fault you can't deliver? If Andrew Connell, MVP, can do it, why can't you? If hawaiianair.com (which as I understand does not use MOSS's WCM features) looks so cool, why can't you brand your portal as successfully?

…Oops, sorry, I kind of drifted off while you were talking there, I was reading an article about how to AJAX-enable my web parts. It says here that I can throw in an UpdatePanel in two minutes! What could go wrong?

And the capper. What kind of crazy world do we live in, where someone is encouraged to learn the most volatile and transient technologies over fundamentals! His post had 11 kicks on DotNetKicks; 11 people agreed with him? He's not alone in his opinions?

So I'm burned out

I'm going to go on an "information diet," for as long as I can hold out; I'll be fine, I've been through this before. No technical learning outside of work, outside of my immediate duties. Shut down the Google Reader, close the book, hide the laptop at home. Not a problem, I'll make it back refreshed.

But if I can summarize my ranting above, it is:

Overexuberance in the current crop of technologies, along with faith in unproven, possibly actively unhelpful or worse future frameworks, makes my job harder, today.

Microsoft's strategy of releasing frameworks at an overwhelming rate has left every Microsoft developer overburdened with technical learning. Microsoft (and we ourselves!) worsen this problem by pushing new, unproven, possibly useless-out-of-the-gate technologies on ourselves, before they are even ready—and this will make my job increasingly harder for the forseeable future.

Aside: Houston ALT.NET 'geek dinner' at Star Pizza 6PM on Monday, July 14th

If you made it this far, then maybe you'll be interested in attending the ALT.NET informal gathering this Monday, July 14th, at 6PM at Star Pizza.

And as always, the "sweet place to hang out" is on the houstonaltdotnet mailing list; all the cool kids are subscribed.

Monday, June 30, 2008 11:27:04 PM UTC 

Quick link: http://www.codeplex.com/SharePointPdfIcon

This is possibly the most important customization you can make to SharePoint. OF ALL TIME.

By default, SharePoint does not include a PDF icon. When you upload a PDF to SharePoint, you see:

This is unacceptable!

Manually adding the PDF icon

I'm not here to tell you how to manually add the PDF icon to your SharePoint farm. Steven Van de Craen already does an excellent job, so I'll just link to him.

But manually adding a PDF icon? So 2006-2007. We're in 2008 people, let's get with the times.

Programmatically adding the PDF icon

Recently Steve Goodyear from Microsoft posted step-by-step details of how to programmatically add a PDF icon to your farm. Which is great.

What Steve did not do, however, was go the extra step and provide a working .WSP file.

Ok. At this point you're asking yourself: "Well Peter, since you're not bothering to tell me how to manually add a PDF icon, and you're not going to tell me how to do it programmatically, then why are we here?"

Introducing the most awesome SharePoint Solution package ever

Introducing: the PDF Icon installer!

I've developed a Solution package to change the dreary, dull, blank icon, to a dynamic, Web 2.0, hot hot hot PDF icon!

Feedback

If something is terrible, let me know and I'll fix it. Issues/Discussion page on the CodePlex project page. Or if it's really terrible, email me direct :)

Where to get it

http://www.codeplex.com/SharePointPdfIcon

Saturday, June 28, 2008 11:25:00 PM UTC 

Yesterday and today I attended the SUGDC Summer Regional SharePoint Conference. And by "Regional", we mean Washington, DC and surrounding provinces and territories. Telling the story via graphics:

I'll point out I didn't drive, I flew, though the flying experience probably took longer on the way up than driving would have. Yes, I'm aware that driving can take quite a while; yes, my flight up was nightmarish.

People

As I've been told before, the most important thing about attending a conference is not its sessions; it's the people you meet. I'm not going to call out names, but it was great to be able to meet a bunch of people of differing skillsets and backgrounds. And by differing skillsets, I mean "expert," "expert PLUS," and "Super expert plus, TURBO"—we're all pros here. Of course, of course; me too.

Fun Tidbits in the Sessions

Since I did dutifully take notes, I'll share the fun bits here:

• Errin (whose company is based out of Houston) presented an excellent overview of SharePoint's various capabilities and what projects they're doing. A good throwaway example is the slide that declared: "Documentum: $1.2M annual license. SharePoint: $400K one time fee." …the point being, even if you have to pay to customize, SharePoint is still the cheaper choice.
  ANYWAY, the thing that made this interesting (and different) is that he has done the projects—they're real, they're not all marketing hype. Believe the SharePoint pie chart! Well, kinda anyway, we'll get to that below.
• Errin also mentioned the importance of getting 'quick wins' in selling your SharePoint deployment. Throughout the weekend several others hammered this home as well, and it makes good sense: Step 1: find something that is a good match for SharePoint and is generally easy to do; Step 2: do that thing; Step 3: profit! Funny enough, I hear the same thing spoken about SOA implementations, although the guidance I heard was more like "3-5 projects." Since parts of SharePoint are designed to solve common business problems, you'll find it's, gasp, actually useful for your organization too!
• Interesting: he says the magic # to extract your storage requirements from your raw data is about 3.5. So if you have 100GB of files sitting on a shared drive that you plan to get into SharePoint, then you will need roughly 350GB of storage to accommodate.
• My Site governance: if we get the slide deck, I'll recommend looking at it to find a list of all the things that can go wrong with your My Sites. We're all aware of the big offenses, wait, let me capitalize that: Big Offenses—but we're not sure what else to look out for. Check his slide deck, there's a good summary there.
• Onto the next session! The Red Cross folk presented on their Communities of Practice, AKA their "Neighborhoods", which I'm loosely defining as "small targeted online communities." E.g. for the Red Cross, something many people are interested in is Measles. I don't know why either, something to do with saving lives. Anyway, my take on this whole thing is that the technical problem is solved, and has been since Philip Greenspun's ArsDigita started doing this sort of thing for corporations in the 90s. The only thing that remains is the human factors—getting people to, you know, use the stuff that's out there.
• Morbid tidbit: one of our presenters (I will withhold company) mentioned that one of the great catalysts spurring people to adopt SharePoint for knowledge management was a big pending layoff (RIF). Knowledge transfer was a real, immediate problem for them, and SharePoint provided a good solution. Takeaway: big layoffs drive SharePoint adoption! Slap that on the side of a bus and drive it around at the next conference!
• Hilarious quote: "You want to use a wiki? How much do you use the discussion lists you have on your site? None? Ok."
• As an aside: for the record, you are no longer allowed to use the term "wikis and blogs," as if they belong together. Small wikis are great. Wikipedia is great. Content tied to RSS feeds, which also allows comments, are great. Blogs that you can find on Technorati and can add to your subscriptions in Google Reader are great.  But in none of the 5 situations above, are you combining both "wikis" and "blogs" into one solution. You're not. Furthermore, nowhere are you even combining your intranet-facing content with your public-facing content. "Wikis and blogs" is a meaningless term, and it's growing ever more popular as the Enterprise 2.0 cloud blows in. I will talk about Enterprise 2.0 some other time; the summary is "part duh, part new good things, part money/hype/vendor."
• Also driven home: the fact that SharePoint implementations should not be "hardware + software + configuration + customization" only. It should include a great deal of effort on PEOPLE, PROCESS, and TRAINING. I'm with you there 100%. Training is always a good choice.
• Awesome nugget: when asked how to prevent sensitive or covered-under-regulation documents from being uploaded to SharePoint, Melvin's response was "what do you do for email?" Their inevitable answer is "nothing; we can't control email." The implication then, is that "oh, then why am I suddenly required to control SharePoint?" Melvin claims we can tell people that we will only hold SharePoint to the same standards to which we hold our email systems. I don't know about you, but this is an awesome "organizational hack" and I'm going to try it out.
• Job roundtable: it is clear that a) there's a lot of demand, b) there are at least three distinct roles for SharePoint, c) the "talent shortage" problem is only going to get worse. My advice: train up someone with no SharePoint-specific experience, almost as an intern-type situation. As you may imagine, this was a rowdy session and had lots of crowd feedback.
• Greg Galipeau - attended this intro to SharePoint site definitions development. What's fun is sitting next to a total newbie to SharePoint who is asking, "now what do I do to start a SharePoint project? Which project do I pick?" What was not fun was to realize that, while I was sleeping, WSPBuilder (my tool of choice) went out and added a bunch of features of which I'm unaware. So I'm out of touch. Also out of touch with: STSDEV. Also out of touch with: VSeWSS v1.2 specifically.
• Tony Byrne of CMSWatch, presenting portions of the CMSWatch report as his presentation. I want to talk about this one for a long time. I just want to focus on three things in his presentation:
• One: take a look at what you need, before deciding on SharePoint. I know a lot of us back into SharePoint and then look around, after having purchased the product, and say, "okay, let's try implementing <feature A>! I read it works great!" If you get nothing else from his presentation/report, it's that SharePoint is not equally good at everything. His quote was "it can do anything, more or less."
• Two: The other thing that's unique is that he focuses on the actual product we have today. This is where I think a big disconnect exists: even outside of marketing influence, people believe SharePoint will somehow get better, and assume that improvement is 'inevitable'. If you take away this second thing, just think for a second: what do we have, now, today? Not what we believe the product will look like in the future—what do we have now. Biggest example for me: Don't look at Silverlight 2.0 seriously, yet.
• Third: He claims that "SharePoint is a guild". Which is offensive, but, when you think about it long enough, yeah, it kinda fits. One quick rebuttal: if SharePoint's a guild (which I'm admitting), then it's the easiest guild to enter of all the enterprise systems. If you want to take something positive out of this, let it be: we still have a long way to go before picking up SharePoint is 'easy'. I could talk a long time about this, but will cut short.
• I want to do a separate post on his presentation. Summary: even if you're offended at times, he offers perspective, based on real research/investigation—which is something unique.
• Day 2: Sahil Malik presented on .NET 3.5 topics. I think I have an aversion to developing advanced customizations in SharePoint. This includes basically everything he presented, including hosting WCF in SharePoint 2007, using .NET 3.5 in SharePoint (requires some server config to enable .NET 3.5), and AJAX (Atlas). If I can see it working, even in a demo, I start to believe it can work; until then I'm skeptical. So, anyway, I now (as of ~11AM this morning) believe WCF can work in SharePoint 2007.
• Also interesting, Sahil points out you should use a single "big honkin'" (that's technical jargon for large) physical SQL Server, in conjunction with dev VMs. The more obvious/default choice would be to host your SQL Server instance on each VM; his setup combines all the SQL instances. He says this is best for performance reasons, which, now that I think about it, works.
• SharePoint for small businesses - actually I'm just writing this bullet point to apologize: I came in halfway through and zoned out for the rest. I blame my stomach, I was starving.
• Random quote: "if you don't have policies, you're up a crik."
• Implementing a PMO (and using SharePoint)
• This was an interesting talk because it focused more on the human factors than SharePoint. Something that should be obvious is that if you don't have the process down, installing MOSS or MOPS will not fix your process for you.
• Quote: "…PMO is not a project site [in SharePoint], it's not just rolling up all your project sites."
• Tip: access disparate data, don't recreate it
• Tip: "if I can see everything I need in one place, then … (handwriting is slow…general idea of "I'll be effective)"
• "Transparency" - sometimes there are fights because people don't want to be transparent. Ooh, I feel that one.
• Speaker prefers Lean, but wisely didn't use the word "Lean" anywhere in his presentation. :) He just said "The Toyota model"
• Fun quote for my PMI coworkers: "PMBOK is starting to get stale." This is fun because I can imagine their response.

I just read that, that was a lot of text

Wow, I need to learn to edit, bad me. Well, no way I'm going back and attempting to edit that behemoth; if you made it this far, then there must have been something good in there to keep you reading. Or you're a skimmer.

A+ would buy again

I do generally recommend this conference, especially to those of you in the area, as:

a) It's on a Friday/Saturday, which means you only lose one workday and one weekend day; (strikes a compromise between missing work and hating life)

b) The management track was excellent and had tidbits you can find nowhere else…well, nowhere else besides another conference or a $1400 report;

c) There was no "Intro to Silverlight" session.

Wednesday, June 18, 2008 2:02:02 AM UTC 

…which is very little. I will state for the record, that all this is public knowledge, primarily because I don't have the hookups to get some sweet sweet NDA action. Anyway, onwards.

The following is everything I could find (and ask others to find on my behalf) publicly available about SharePoint. There's not much we know yet.

Quick summary is: beta's coming soonish, MDM is a new slice in the feature pie chart; Enterprise 2.0; FAST search; claims-based auth; bunch of stuff they probably haven't announced. A lot of this has not been specifically promised for SharePoint 14, but may appear in vNextNext, or vNextNever. Who knows, I don't.

Onwards!

Early access - beta soon?

Office 14 TAP: Nominations are open

SharePoint 14 - available internally since February

Surprising/big-impact changes

Master Data Management

SharePoint may use claims-based auth

Thoughts on SharePoint and FAST search

Random SharePoint 14 tidbits

Enterprise 2.0 conference SharePoint tidbits

SharePoint Lists improvements

Ship date in 2009?

Transcript of Bill Gates' SPConference 2008 speech

SPConference 2008 writeup - Microsoft's strategy for vNext

MVP summit 2008 recap

Access Web Access: Speculation

The Bill Gates Interview

OOXML and PDF support

WinSuperSite Office 14 FAQ

64-bit only

<