Paul Vick has an excellent post about white elephant projects at Microsoft entitled Black hole projects  where he writes

I left Office just about the time that Netdocs really started going, but I do know a few people who invested quite a few years of their lives into it. I can't say that I know much more than Steve about it, but it did get me thinking about other "black hole projects" at Microsoft. There was one I was very close to earlier in my career that I managed not to get myself sucked into and several others that I just watched from afar. None I can really talk about since they never saw the light of day, but it did get me thinking about the peculiar traits of a black hole project. They seem to be:

• They must have absurdly grandiose goals. Something like "fundamentally reimagine the way that people work with computers." Nobody, including the people who originate the goals, has a clear idea what the goals actually mean.
• They must involve throwing out some large existing codebase and rewriting everything from scratch, "the right way, this time."
• They must have completely unrealistic deadlines. Usually this is because they believe that they can rewrite the original codebase in much, much less time than it took to write that codebase in the first place.
• They must have completely unrealistic beliefs about compatibility. Usually this takes the form of believing you can rewrite a huge codebase and preserve all of the little quirks and such without a massive amount of extra effort.
• They are always "six months" from from major deadline that never seems to arrive. Or, if it does arrive, another milestone is added on to the end of the project to compensate.
• They must consume huge amounts of resources, sucking the lifeblood out of one or more established products that make significant amounts of money or have significant marketshare.
• They must take over any group that does anything that relates to their absurdly broad goals, especially if that group is small, focused, has modest goals and actually has a hope of shipping in a reasonable timeframe.
• They must be prominently featured as demos at several company meetings, to the point where people groan "Oh, god, not another demo of this thing. When is it ever going to ship?"
• They usually are prominently talked up by BillG publicly years before shipping/dying a quiet death.
• They usually involve "componetizing" some monolithic application or system. This means that not only are you rewriting a huge amount of code, you're also splitting it up across one or more teams that have to all seamlessly work together.
• As a result of the previous point, they also usually involve absolutely massive integration problems as different teams try madly to get their components working with each other.
• They usually involve rewriting the application or system on top of brand-new technology that has not been proven at a large scale yet. As such, they get to flush out all the scalability problems with the new technology.
• They are usually led by one or more Captain Ahabs, madly pursuing the white whale with absolute conviction, while the deckhands stand around saying "Gee, that whale looks awfully big. I'm not sure we can really take him down."
• Finally, 90% of the time, they must fail and die a flaming death, possibly taking down or damaging other products with it. If they do ship, they must have taken at least 4-5 years to ship and be at least 2 years overdue.

I'm kind of frightened at how easy it was to come up with this list - it all just kind of poured out. Looking back over 12.5 years at Microsoft, I'm also kind of frightened at how many projects this describes. Including some projects that are ongoing at the moment.

Someone who works with me at MSN mentioned that there was a time the Netdocs team was larger than the entire Microsoft Office product unit combined. Scary. As Paul mentions, the sad thing is that there are projects like this that continue to exist at Microsoft even though everybody sees the signs and already knows how the story ends. In fact, you don't even have to work at Microsoft to be able to tell what some of these projects are.

Sad.

I was just completely freaked out a few minutes ago. All of a sudden in the middle of editing some XSLT stylesheets I started to get a resonating hum similar to electronic interference in the base of my skull at regular intervals. I was about to call 911 when I realized it only happened when I was near my monitor or television and stopped when I turned them off. I called a friend and she mentioned that she'd heard that this sometimes happened to people with silver fillings in their teeth. Since I'd just got some dental work done about a week and a half ago I guessed this might have been some static electricity buildup. So I brushed my teeth and now I don't have the weird hum in my head while using the computer anymore.

Unfortunately I couldn't find anything on Google about this.

Looking at the calendar I realized that I have two articles due this month, one for my Extreme XML column on MSDN and another that I promised XML.com a few months ago. I was reminded of this by the following excerpt from Ed Dumbill's recent article On Folly where he wrote

Champion cited two developments of particular interest. The first is E4X, the addition of native XML capabilities to ECMAScript. An implementation of this in the Mozilla project is currently coming to fruition. The second development is "Comega" (aka "Cω"), an extension of C# including native XML data types. (Editor's Note: Watch XML.com for a forthcoming introduction to Comega from Dare Obasanjo.)

So I'm on the hook for an overview of Cω. I started to wonder whether it wouldn't be cool if my Extreme XML column focused deeply on Cω while my XML.com article was an overview of both E4X and Cω. This would save me some effort in coming up with a separate topic for my Extreme XML column but should provide interesting information for both XMl.com readers and MSDN readers. What do you think?

When I first started working on RSS Bandit I wanted an application that looked and acted as much like Microsoft Outlook as possible. Two years and over a hundred thousand downloads latter I realize that there are a number of drawbacks to using this model for reading feeds [or any information for that matter]. Mike Torres describes some of these reasons in his post Why I dig Bloglines, he writes

Part of the problem for me is that applications that look and feel like Microsoft Outlook tend to make me feel like I am working, and I am immediately in "information overload" mode (we get hundreds of pieces of email each day at Microsoft.)  Catching up with friends, reading Scripting.com, or checking out Engadget shouldn't be tedious.  But for some reason, it was.  Until I switched to Bloglines.
...
Anyway, here is what I like about Bloglines:

...

• I can scan dozens of feeds in less than a minute.  With NewsGator for Outlook and other Outlook-style interfaces, it just simply took longer.  Probably because Bloglines shows me the feed in the way it is supposed to be presented - reverse chronological order on a single page.  Not as individual messages that I have to click through. 

...

This is the bane of the current information viewing model paradigm favored by email and newsgroup readers which many RSS aggregators have decided to inherit. The major problem is that the Outlook mail reading paradigm has a fundamental assumption which turns out to be flawed. It assumes you want to read every item you get in your inbox. This flawed assumption leads to the kind of information overload that hampers the productivity of lots of people I know at work. I've met several people who seem to always have hundreds unread items in their email inbox. For this reason I always have to learn who's easier to reach via IM or swinging by their office in person than sending them mail.

Most people I know get four classes of messages in their information aggregators (I am lumping reading email, reading news and reading RSS/Atom feeds into a single category). These are

1. notifications (checkin mails, comments to my blog, etc)
2. headlines (email newsletters, feeds from news sites, etc)
3. messages sent directly to me or that is similarly relevant
4. messages sent to an interest group I am a part of (XML-DEV mailing list, comp.text.xml newsgroup, etc)

The problem is that the typical Outlook inspired information aggregator treats all of the above as being of equal relevance. Even though Outlook does provide mechanisms for managing assigning relevance to incoming messages, they are either hard to find or cumbersome to use.

This is definitely one of the areas that needs to be improved in the world of information aggregators in general and RSS/Atom readers in particular. There are a number of features that I'm working on for the next version of RSS Bandit aimed at making it easier for people to consume information from various sources in a flexible manner according to what relevance they place on the information source.

Torsten has been hard at work on the UI for managing newsgroups in the next version of RSS Bandit. Below is a screenshot of what is currently checked into CVS. We'd love to hear any comments you have.

For example, the View menu behaves like a tabbed pane but we decided against tabs for some technical reasons. Is this confusing? Also I've suggested that we change the buttons on the top left named 'Identity' and 'News Server' to 'Add Identity' and 'Add News Server' to separate the fact that those buttons perform actions while the ones on the right act more like tabs in a tabbed pane. Agree? Disagree?

Speaking of which I need to test the code that handles binary attachments so if you know any public news servers that allow you to subscribe to binary newsgroups, let me now. Unfortunately there aren't any binary newsgroups on news.microsoft.com.

Since I left the XML team at Microsoft they've gone on an impressive hiring spree. Two people who I'd have loved to work with who have joined up after I left are

David Remy: former Director of Product Engineering at Bea Systems, he was responsible for security, web services, and XML for Bea's Weblogic Workshop product line.

Mike Champion: formerly a research and development specialist at Software AG. He was on the W3C's Document Object Model (DOM) Working Group for over three years and was the co-chair of the Web Services Architecture Working Group.

I have to see how quickly I can nag both of them to start blogging. David used to be in charge of the folks who produced XML Beans so I suspect he has all sorts of interesting perspectives on XML programming models. Mike and I have been exchanging mail on XML-DEV for years and now that we can have some of these conversations in person, I work across campus. Irony indeed. :)

According to an article entitled 50 Cent Involved In Scuffle At Airport In Nigeria on AllHipHop.com 

American Hip-Hop star 50 Cent was engaged in a scuffle with the entourage of another rapper in a Lagos, Nigeria airport last night. 50 Cent was in the African nation taking part in the annual Star Mega Jam, which brings top name talent to perform along side popular Nigerian artists.

The incident started in an airplane belonging to the Aviation Development Company, before an aborted trip to Port Harcourt for a final performance. Eyewitnesses stated that Nigerian rapper Eedris Abdulkareem attempted to sit in a seat reserved for the internationally known 50 Cent, but was prevented from doing so.Abdulkareem’s entourage protested, resulting in a brawl inside the airplane.The scuffle carried on to the tarmac of the domestic wing of the Murtala Muhammad Airport, drawing the attention of employee’s and other passengers.

The rapper left without completing the performance due to the incident.

That's kinda messed up. I'm just glad this happened after my mom got 50's autograph when she interviewed him.  

Watching the various kinds of feedback about MSN Spaces has been illuminating. You have the geeks posting about not having enough power user features such as Robert Scoble in his post MSN Spaces isn't the blogging service for me, there are the average non-technical users who've been giving us great feedback about the sites usability and then there are the analysts who've clued in to the social software revolution happening at MSN.

It starts with Joe Wilcox (of Jupiter Research) in his post MSN Spaces, First Take who writes

The data JupiterResearch has on blogging suggests the large body of blogs aren't widely read--and for good reason, I figure. The interest is limited. So, Jane is struggling with her boyfriend Tarzan and blogs about her travails. But, maybe, only some friends follow the breakup blog. To most people, it's just another romance gone bad, and there are plenty of those to be found.

So MSN Spaces takes a different approach, by extending existing assets to create community. For starters, public profiles, such as for MSN Messenger or MSN Chat, tie into the individual's blogspace. Additionally, Microsoft uses MSN Messenger to create presence and even limit access. For example, blogspace access can be limited to people on the MSN Messenger buddy list. That's a smart use of IM presence. Similarly, IM buddies are notified when a user has updated his or her MSN Spaces blogsite.

Additionally, Microsoft adds a wall of protection for people that might want to blog for some folks but not the whole World Wide Web. Users can restrict blogspace access to people they choose from their MSN address book. Additionally, by default, trackbacks to blogspace content is restricted to other MSN Spaces sites. The user can open access to the entire Web or restrict trackbacks altogether. For people looking to blog for a community of friends or family, the privacy protection makes sense. As a parent, I feel uneasy about posting pics of my daughter in a blog photo album for the entire world to see. MSN Spaces would create a safe haven for just the people I would want to see the pictures.

In a follow-up blog, I'll look at some of the other MSN Spaces community-oriented features.

When I look at Microsoft's first foray into blogging, I see two development undercurrents: An admirabe effort to bring blogging to the masses and to not bring those blogs to the masses but their community of friends and family most likely to read the content.

Unsurprisingly, this same undercurrent was noted in the blog post entitled MSN Spaces will make blogs communication tools by Charlene Li of Forrester Research who wrote

MSN Spaces is very full featured users can add posts from cell phones as well as via email. Drag-and-drop layout design and pre-fabbed templates make creating a custom look and feel a cinch. A couple of other innovations:

+ Permissions are linked into MSN Messenger and MSN Address books. Only .NET Passport email addresses are accepted.

+ Integration with MSN Photos and MSN Music to upload photo albums and playlists easily. Moreover, users can click on a playlist and sample or purchase the song or album.

+ Put Spaces content elsewhere on MSN. MSN Hotmail and Messenger have a new feature called Contact Cards that will take the latest post or photo added to your Space and displays it next to your contact information. When you update your Space, your name changes its like indicating the presence of new content, rather than your actual presence.

Notice a trend here? Theres heavy integration of Spaces into the whole MSN communication suite of email and instant messaging. I think this is very smart, especially as MSN hopes to attract a new audience group to blogging. The next wave of bloggers is going to look very different from todays blogger their motivation will be on sharing experiences rather than having a place for their ideas and opinions.

The feedback isn't all rosy. In followup posts Joe Wilcox states that the poor performance (our team has been working overtime on resolving various issues here and the site is a lot better than when he wrote the post), its preference for for users browsing with Internet Explorer and the hubbub around content moderation will keep MSN Spaces from becoming a challenge to existing players in this area. He isn't the only one to complain about the IE specific features of MSN Spaces, Adam Bosworth also complained about this on his MSN Space (Yes, Adam Bosworth of Google has an MSN Space).

We're listening to all this feedback and would like to thank everyone who's acknowledging our innovations in this area.

A lot of people who've heard about MSN Spaces have also seen or heard about the the MSN Spaces: seven dirty blogs post on Boing Boing. In fact that post is so popular it's the first result currently returned by searching Google for 'MSN Spaces', this search also results in an ad for SixApart's TypePad blog hosting service which is also interesting but something I'll post about another day.

Mike Connelly (the Group Program Manager of the Spaces team) has a post entitled Comments on Content Moderation  where he writes

One of our main goals for Spaces was to create a platform for people to share their thoughts and feelings with their friends and the outside world.  However, we wanted to make Spaces usable by not only the people who are blogging today, but also be approachable by the general internet user, who might not have heard of blogging previously, or been given an opportunity to try it out.

Unfortunately, whenever you create an open platform for people to say whatever they want, and open it up to the wide world (14 languages, in 26 different markets), there is always a handful of people who spoil the party, and post a bunch of inappropriate (and in some cases illegal) stuff. And to make matters worse, what exactly is deemed “appropriate” or not is very subjective, not only from person to person, but from country to country.

So, we need to do what we can to make our platform available for people to use in the way they like, but we want to keep wildly inappropriate stuff outside of public forums.
...
However, there is 1% left over.  Not everyone on the internet subscribes to the same "netiquette" that some of us who have been around for awhile know and understand. So, we do one proactive thing, to make the world a little less bumpy. We block a set of specific words from being used in 3 areas: the url you select, the title of your Space, and the title of your blog entry. These three fields are reused and displayed in a variety of areas, like search results, so we thought it would be a little thing we could do to cut down on the obvious cases that would most easily offend.

As part of trying to get Spaces to be something that is widely adopted by the general population as opposed to a small subset of society (most estimates are that less than 1% of Americans have weblogs and even at Microsoft where we are all mostly completely comfortable online there are about 3% of the employees blogging) the decision was made to discourage the usage of inappropriate language in parts of the space that would be reused outside the context of the space. One can use whatever language they want in posts, comments, and their various lists. However post titles, blog titles and URLs can't contain words certain "inappropriate" words [for some definition of inappropriate].

So far although I've seen lots of posts deriding the simplistic nature of the profanity filter [of course, every profanity filter I've seen can be tricked or causes a large number of false positives] I've not seen many posts from existing or potential users of Spaces about how they feel about this. What are your thoughts?  

Don Smith continues our conversation on parameters to XML Web Service methods in his post Versioning Web Service Parameters where he writes

Dare makes a few comments about one of my previous posts so I thought - in true blogsphere fashion - I'd follow-up in a new post.
...
I think it's also important to make a distinction between different kinds of Web Services, even if they're broad and sweeping. There is a considerable difference between a service-oriented Web Service and one that is not service-oriented. Perhaps my choice of GetTemp( TempRequest ) was a poor one. Service-oriented operations are very course-grained because they represent a business process. Because of this, the service interface is not likely to change (unless the organization is going to stop offering the service). However, the data pieces that service will require could very possibly evolve over time. Therefore, it's important to be able to version the service interface and the parameters of the operations independently. If you agree at this point, then we need a way to identify what version of the operation's inputs are being used. The only way to accomplish this with multiple parameters is for one of the parameters, which has nothing to do with the business logic of the operation, to contain version information. With a single parameter, we can maintain a straightforward experience for the client developer.

I agree with Don that his original example was probably not the best to illustrate his point. The problem I had with his original post was that it was a general recommendation which in my experience tend to never hold in most cases let alone all of them. The complexity of the service and the expected evolutionary path of the service end point should dictate whether the additional complexity of using a single parameter that contains versioning information and the actual input the method should be used or not.

Since I tend to agree with the excerpted paragraph  about service oriented methods being coarse grained which implies that one should be able to version parameters, I think Don and I are now in violent agreement. :)