A friend of mine sent me a link to a declassified WWII era document called the "Simple Sabotage Field Manual" that was the subject of a presentation at the recent Enterprise 2.0 conference. It is a fascinating read if you do any work managing collaborative efforts (anything involving a team) or build systems to facilitate collaboration (like SharePoint).
It gives advice on how to deliberately screw things up but can also be read as an anti-pattern of behaviors to avoid yourself and to watch for in those you manage or collaborate with. The evil genius of this guide is that all of the techniques it advises are destructive behaviors that normal people exhibit on a daily basis. So, if you were to do these things in a theater of war you could hurt the enemy while maintaining plausible deniability and avoid a firing squad.
I guarantee that you’ve seen most or all of these in action. I know I have over the many consulting projects I’ve done here in Atlanta and not just the ones involving SharePoint.
Here are some of my favorites:
Sabotage Under the Guise of Process
- Insist on doing everything through "channels." Never permit short-cuts to be taken in order to expedite decisions.
- When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible — never less than five.
- Bring up irrelevant issues as frequently as possible.
- Haggle over precise wordings of communications, minutes, resolutions.
- Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
- Advocate "caution." Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on.
Sabotage Via Project Management
- Do everything possible to delay the delivery of orders. Even though parts of an order may be ready beforehand, don’t deliver it until it is completely ready.
- In making work assignments, always sign out the unimportant jobs first. See that the important jobs are assigned to inefficient workers of poor machines.
- Insist on perfect work in relatively unimportant products; send back for refinishing those which have the least flaw. Approve other defective parts whose flaws are not visible to the naked eye.
- When training new workers, give incomplete or misleading instructions.
- Hold conferences when there is more critical work to be done.
- Multiply paper work in plausible ways. Start duplicate files.
- Apply all regulations to the last letter.
Sabotage Your Team Via Poor Work
- Work slowly. Think out ways to increase the number of movements necessary on your job
- Contrive as many interruptions to your work as you can
- Do your work poorly and blame it on bad tools
- Never pass on your skill and experience to a new or less skillful worker
- Give lengthy and incomprehensible explanations when questioned
- Act stupid (My favorite)
- Be as irritable and quarrelsome as possible without getting yourself into trouble
I predict it won’t be long before someone writes a best-selling business book based on this guide.
Author: Doug Ware
My previous post was a matrix of feature scopes.
Dan Attis pointed me to the SDK page on MSDN, to which I replied, ‘Not a handy matrix!’ That content on the page mentioned was, in fact, the source of the matrix, but I got it from the SDK itself (as in the thing you install). That’s too bad, because there in the comments section in the online version was a comment that ListTemplate can scope to Site. I’ve been working around that non-existent limitation for a long time.
Now, I was curious, when was this comment made? I checked the history on the comment and discovered:
That’s right! Joel Triemstra took the time over a year ago to correct this mistake in the online content and one year later the article is still wrong.
- Don’t use the SDK installation because it doesn’t include the community comments.
- Make corrections where you can, because people will read them, if only online.
I’m very disappointed that it’s still not correct in the article body, but I can testify that there have been many corrections made over the last two SDK editions. So, I give a lot of credit where there are improvements. But, my suggestion to the SDK maintainers is: if you can’t address every comment between releases, find a way to include the comments in the installed library.
Well, no sooner do I write that I am not a big fan of VSeWSS that I discover 1.1 is released. I just downloaded it and ran through a few of the reasons why I didn’t like the previous version and why I thought 1.1 CTP showed promise and I have to say after a very cursory review that 1.1 might not suck. In fact, I think it looks pretty good!
It remains to be seen whether I will ditch my personal VS template and wspbuilder in favor of the extensions or if I will find them to be complimentary, but I must say that on the surface VSeWSS 1.1 looks very good indeed! And, if nothing else, the team that makes it has made huge strides in the last few months. Kudos!
You can get the extensions here.
I get a lot of questions about my VM configuration and I think I might as well post it here.
First off, although I appreciate that Virtual PC and Server are free, I use VMWare Workstation. You can evaluate or buy it here: http://www.vmware.com/products/ws/. If I had to sum up why VMWare works better for me than the Microsoft offerings in one word, I’d say, ‘snapshots’.
When developing in SharePoint, it is all too easy to inadvertently mess up the server. One thing I do all the time when I am in a hurry is delete my Shared Services Provider instead of my intended Web application (I swear I’ve done it 1000 times). Snapshots make restoring my development environment to a known good configuration fast and easy.
So, what is installed on my VM?
First off, I run Windows 2003 Standard + MOSS whatever version. This depends on the project and ranges from WSS 3.0 SP1 to MOSS Enterprise SP1.
Beyond that I recommend:
- Visual Studio Professional. I still run 2005 SP1, but that’s only because I haven’t got round to installing 2008.
- WSS 3.0 SDK. It’s available here.
- MOSS SDK (if the project is MOSS). It’s available here.
- Of course I always install my own eLumenotion SharePoint Skinner available here.
- WSPBuilder is a must. You can get it here. If you are creating DDF files and manifest.xml files by hand, you are working way too hard!
- The same goes for U2U’s CAML Query Builder. Hat’s off! This is a great time saver and you can find it here.
- You know you’ll need Office 2007!
- Even if you don’t need all of Office 2007, you will need Microsoft Office SharePoint Designer 2007.
- Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation) if you need to develop workflows, and you know you do!
- Internet Explorer Developer Toolbar, is a must when working with styles and other detail work.
- Finally, I usually need Visual Studio Tools for Office 2005 SE. You can get it here.
I am not a big fan of Visual Studio Extensions for Windows SharePoint Services, but the 1.1 CTP does show promise.
Edit: Not long after putting up this post they released Visual Studio Extensions for Windows SharePoint Services 1.1 which looks like a big improvement. You can get it here.
Author: Doug Ware
The usage data reports in WSS and MOSS aren’t terribly useful. I’ve been meaning to find an alternative for awhile and a couple weeks ago a convergence of events drove me to it.
As I mentioned in an earlier post I have a small ecommerce site now and the search engine optimization process is ongoing. I’m using a canned solution that supports Google Analytics. Around the same time the rug store opened, a friend suggested I consider using FeedBurner for my blog. Like Google Analytics, FeedBurner provides some analytics and, most importantly for me, re-syndicates a blog’s list feed. After a few days of using both out of curiosity I took a look at a third option, a web log analyzer. The one I chose after a 5 second internet search is called WebLog Expert.
Both Google Analytics and FeedBurner work by inserting a little Java Script into your site that calls into their services using an identifier that identifies your web site. Both are free and both are owned by Google. Configuration was relatively easy by following the instructions provided by each.
I started by configuring the SharePoint blog for FeedBurner.
With it I can see at a glance how many people are visiting the blog,
what pages they look at while they are here,
and where they came from and if they clicked on any outgoing links.
My only real complaint about the FeedBurner data is that the "Top 20" mode most of the data displays use has no drilldown. So, in cases where you have a lot of instances, like search terms or referrers, that are all tied at 1 each you can’t see all of the information.
I configured FeedBurner on the blog site as its features are all about blogs. But, I have a site collection, and if you look at the incoming report you will see that one of the referrers listed is www.elumenotion.com with 11 referrals. So, the FeedBurner data is incomplete with regards to my whole site.
I configured Google Analytics for the site collection by putting the appropriate java script in the master pages for the root web and the blog.
Analytics provides much more detail and some cool eye candy!
I could spend a lot of time talking about Google Analytics feature set. It has a lot to offer and it’s free. You can see in detail where visitors come from, what brought them there, how they navigated your site, what links they followed, etc. It even offers an overlay of your site that allows you to visually gauge the popularity of your links and the navigation paths. I highly recommend it.
But still, there was one important element of my site that neither of these tools could give me much any insight.
The reason I went to FeedBurner in the first place was to re-syndicate and get information about my RSS Feed.
FeedBurner is great for this compared to SharePoint because it offers no visibility to the list feed at all, but all I can see on FeedBurner are the stats of subscribers since I configured FeedBurner.
This brought me to option three, web log analysis.
When you create a web application in Central Admin, the IIS web site is configured for logging.
For some reason, the log is not configured to store information about referrers by default. You can change this by clicking Properties and selecting the appropriate check boxes.
The biggest advantage to doing web log analysis is that it doesn’t require any special java script on your site and it doesn’t depend on tracking cookies. Your ability to visualize the data is limited only by the tools you select. The disadvantage is that you have to have administrator access to the server to configure it. Higher end tools support report generation and routing. So if you are in a large organization, chances are there is something available and you might be able to talk the folks in the operations center into getting you the data if you ask.
I used a tool called WebLog Expert. Via the web logs it provides the same sort of information I get for Google Analytics, but it gives the most complete and accurate data.
For now I think I’ll continue to use all three tools as each has strengths the others lack.
I’ve learned a few things from my analysis.
The first is that my request for people to switch to the FeedBurner list feed on October 2nd was completely ignored! As you can see from the chart, the original list feed still accounts for around half of my traffic. However, because the rss links no longer point to it, it isn’t growing.
The second was that I almost never used the term ‘MOSS’ and so unless the search was ‘WSS’ or ‘SharePoint’ people would not find me.
Third, this truly is a World Wide Web. I’ve had a lot of fun with my 5 year old daughter looking at the map overlay to see where our visitors come from and she is learning a little geography in the process!