A couple friends and I exchange links and accompany commentary and discussion about collaborative software now-and-then. And by “collaborative software,” at the moment, I mean weblogs and wikis. I was sending off another link this morning, and I realized I should make a public group/list for this stuff. So, I did.

And here’s the ATOM feed of all new messages.

I created a Google Group called “collab”, you’re free to join if you’d like to shoot the shit on the topic.

Defining the Problem Before the Solution

I’ve been reading Michael Jackson’s Software Requirements & Specifications. One of his big points is that us software developers, at the requirements and specification stage of software development need to focus on defining and framing the problems that the software will solve. And, of course, we don’t:

An inability to discuss problems explicitly has been one of the most glaring deficiencies of software practice and theory. Again and again writers on development method[s] claim to offer an analysis of a problem when in fact they offer only an outline of a solution, leaving the problem unexplored and unexplained. Their readers must work out their own answers to the question: If this is the solution, what was the problem?

It’s a common idea, even a cliché at this point, to say that your requirements and specification need to avoid talking about the implementation of the software. You need to separate out a description of the problem, or user-goals, your software addresses (the “Problem Frame” in Jackson’s lingo), from the architecture, design, implementation, and testing of the solution to that problem.

I’ve always asked myself why this is the case: what’s wrong with mixing the two together?

I don’t have it all sorted out in my head (probably never will, huh?), but here are some thoughts, driven by the anti-patterns you’re trying to avoid by focusing on the problem before the solution:

  • The Golden Hammer. By jumping to the solution, you begin to re-frame the problem with a bias towards the solution you want. You’re really hot to use some new technology, so whatever problems you come across, you force the problem’s solution to fit into the constraints of that new technology. J2EE, Web Services, XML, and Web Applications are good examples of this happening. Those are exciting technologies, and it’s “easy,” and often vendor-encouraged, to cram whatever problem you have into those solutions.
  • Slipping Through the Cracks. Once you start focusing on the solution, you might forget to go back and make sure you’ve fully explored the problem. You get your nice solution, spend time to design/prototype/develop it, and then you realize that you didn’t understand the problem well enough, leaving out key pieces that make your solution not quite right.

    Another aspect of Slipping Through the Cracks is that, during the creation of an Almighty Thud, all of the people who are supposed to be verifying the correctness of the requirements/specification over-look important things in favor of focusing on detailed solution discussion. That is, the analysis part of the cycle doesn’t perform all the analysis it needs to. I’m of course deeply cynical about any process that’s so water-fall, but we all have to deal with it, like it or not.

  • Gold Plating. Slightly related to the above, Gold Plating happens when you don’t focus on simplifying the problem, and instead jump right into creating a solution for (what you think is) a complex problem. That is, the problem you were trying to solve was actually more simple than you’d thought, but because you didn’t spend enough time figuring out how simple the problem was, or simplifying the problem, you assumed it was complex. Thus, your solution ends up being overly complex, often times doing too much, and sucking up too much time and money to design, implement, test, and support. I see this all the damn time.

That’s just three reasons I can think of. I know that plenty of you, dear readers, have experience with the cart-before-the-horse problem. Anyone care to contribute anecdotes or observations?

(As a footnote, Jackson’s book is an excellent pair up with Cohn’s User Stories Applied.)

(Footnote 2: Man, I’ll never be able to spell “requirments” correctly. After all these years, I always forget that extra “e”.)


I don’t know what it is — the civic part of my American upbringing, probably — but it sure is exciting to see an election with over 70% turnout.

There’s plenty of room to be extremely cynical about voting: even our man Benny F., seeming stellar believer in “The People” (the white, rich ones of his day probably…yadda, yadda…as the cliché-refrain goes) is said to have quipped “Democracy is two wolves and a lamb voting on what to have for lunch.” Indeed, I’m

not too thrilled
about the causes of this effect of voting…sometimes going way off my rocker to express that frustration.

Nonetheless, I sure do like the idea of voting, and reading about it in action is thrilling. Few things are more consistent with the way I think than universal suffrage. The “universal” part of that ideal is rarely, if ever reached, but as long as there’s continuous movement towards it, there’s enough hope to push that big boulder back up the hill every time it comes tumbling back down.

Re: Enterprise Blogging in Practice, Notes

Obviously, I’m glad so many people enjoyed the post. A lot of people focused on my statement that introducing blogs hadn’t been a ragging success. I wouldn’t label the blogs as a failure at all. But, I would say that, as always, change takes much longer than I would hope it would. This is a basic fact of any company of course, things happen slowly, esp. when they’re not the primary focus of the business.

Scale | Free wrote:

So, although it’s probably easier to make the initial beachhead in IT / development and other technical departments, it’s probably harder to get a blogging culture established.

And Lunt said,

In addition, the reality is that change in an established company isn’t quick. The blog system takes time to establish a trust base and move people into using it. The ROI sell isn’t as obvious as email.

It Just Takes Time

On the other hand, as each week goes by, the blogs seem to be getting more traction, and are becoming a more useful tool for those who use them to manage their presence and efforts in the company.

So, I think that
you should get your hopes up
. Just be patient when everyone in the company
isn’t blogging the second day after you install the blogging software ;>

Blogging Frequency

Ed also raised this interesting point, that I’ve noticed is very true for myself as well:

I don’t know about you guys, but I’ve noticed that my blogging tends to rise during peak stress times, it’s almost cathartic, and oftentimes makes me more productive in aggregate. But, as with other contrarian realizations, you probably don’t expect the Pointy-Haired Bosses to get it, so you just post to your offsite blog instead of the enterprise blog where you could actually post useful information.


I also noted that figuring out how to integrate blogging into daily work life has been challenging. My co-workers and I have tried out several aggregators, of various types, and I we’re finally (after all this time) settling on NewsGator Outlook Edition. We’re evaluating the trial, and we’ll probably purchase it if we end up liking it.

I thought I wouldn’t like it — simply because it lives in Outlook…I hate Outlook — but I think it does an excellent job of seamlessly integrating RSS reading into daily work life…despite being in Outlook ;> It has a few UI features that annoy the crap out of me (like opening up that news Page all the time when I accidentally click something), but overall I really like it.

As we use that tool more, I’m sure I’ll have more to report.

Tags: , , , .

Tags: , , , .

MacCast: Another Podcast Recommendation

I’m listening to the current episode of MacCast, which so far is doing an excellent job of aggregating all the current Mac news and rumors. I hadn’t thought about it before, buy podcasting is a perfect medium for this sort of aggregating of news, ideas, and the web/blog-o-sphere in general. I don’t have enough interest in Apple news and rumors to read all the Mac rumor and news sites. I don’t really want to drink from the fire-hose, as it were. But I’m fine with listening to a summarized, “edited” show that pulls all that together.

And, MacCast seems to be doing that just fine. For Example:

  • Apple minis are selling at Target. This is interesting because it’s a new dist. channel for Apple, a very consumer/everyman channel. If they showed up at Wal-Mart, that’d be a huge tipping-point.
  • New colors for iPod minis are rumored to be coming out this week.
  • Faster PowerBooks are rumored to be coming out this week…but then, not a week goes by without that rumor ;>

Yup. So, if you’re sync’ed up with my podcasting habits and tastes, I’d add MacCast to your ipodder list.

(Here’s some past recommendations.)

Tags: , .

Navigation in Webapps Not So Important?

From “Navigation blindness”:

According to Jakob Nielsen there is no need to link to all sections from each and every page on a site. We should limit pervasive navigation to five or six basic features and let people go back to the front page, if they want to start from the top. Instead, we should focus on getting users to what they want and provide useful links to related content.

In Mark Hurst’s opinion designers put too much effort into content organisation and design of navigation systems. Organising a site into sections and subsections does not by itself create a good user experience. What matters is whether users can quickly and easily advance to the next step in the pursuit for their goal.

(Via Gerd.)

Enterprise Blogging in Practice, Notes

In addition sparking off some thoughts about RSS security, the most recent Gillmor Gang got me to thinking that I should write-up my experiences with blogging behind the firewall, or “Enterprise Blogging” to use a trade-raggy phrase.

(I don’t like tooting my own horn, so pardon any tooting you hear. It’s not intentional.)

Setting Up the Blogs

A little under a year ago or so, I started experimenting with weblogs behind the firewall. I setup an instance of Pebble on one of my spare machines and asked a net-admin type to create an alias, “blogs” for the machine. So, folks on our intranet could type “blogs” into their web browser, and see a list of all the weblogs and their RSS feeds.

I didn’t ask anyone, or allocate time for it, I just installed it and told people in my group about it. This had worked out well 3 or so years ago when I setup a wiki, and at a previous company where I’d setup another wiki.

Eventually, I switched over to an instance of Roller, which had built in support for people signing up for their own accounts (Pebble didn’t, I had to manually create an account each time). Roller also has more editors and, so far, has been easy to extend with a JSP page here and there.

There’s executive sponsorship for the blogs (since last Fall), but there isn’t anyone whose job it is to take care, maintain, or develop them.

Current Use

Last I checked, we had about 80 people signed up for a weblog. A small percentage of those are “active” posters. Lots of people sign up for an account, make an initial post, and then never post again. A small subset of people post several times a day. And the largest segment of people post once a week or so.

At the department level, I wouldn’t say the blogs have been a wide-reaching, ragging success, primarily because people don’t post to them as much as you’d hope. However, for the people who do post to and read the blogs,
they’ve been very successful

What People Post

  • News stories in our industry and about our company.
  • Status of various test and performance clusters. So, instead of having to send out emails or answer phones all the time, you can say, “just subscribe to the performance cluster weblog. It’s always up-to-date with performance test status.”
  • Brain-storming about strategy, feature sets, and process.
  • Sharing customer visit/phone call notes.
  • The “I exist” posts. Like I said, a lot of people just post one initial, “I’m here!” post and then disappear.
  • Soliciting ideas/help. For example, one person recently posted the age old question, “when should I use wikis vs. weblogs?”
  • Off-topic posts, like pictures of stars (the space ones, not the Hollywood types) or what the frozen burgers in the freezer look and taste like.

Except for very early on (when I did them), other than the performance status posts, there hasn’t been a lot of “status update” posting. I thought that’d be the primary use of the blogs, but people haven’t taken to that use-case at all.

Problems with Blogs Behind the Firewall

The “problems” with “blogs for work” have been almost identical to the problems with wikis for work.

Most all of the problems have to do with getting lots of people to buy into, then read and post to the weblogs. There are, of course, some technical problems, but the bulk of them are related to pushing the blogs into the Plateau of Productivity…I don’t know if we’ve even reached the Peak of Inflated Expectations yet ;>

Here’s the problems I can think of, along with possible solutions, gotchas, lessons learned, and other notes that might be helpful to other people doing blogs behind the firewall:

Lack of time to maintain and work on blogs

Anyone in IT now-a-days is doing the work of 2-4 people. We’ve all got deadlines for other things. Finding the time to work on the weblogs, to do even the simplest 1/2 hour task, is extremely difficult. As such, technologically, the weblogs are pretty much frozen in the state I initially installed them in/at. For example, we need to move them to a better server, but there’s no time for that.

Unless you can get the time, the lesson learned here is to make the initial cut of your blogs install as ideal as possible. Get the beefiest server you can, the best blogging software, etc. If you’re lucky enough to find the time to set it up initially, more than likely, you won’t have time to improve it later. The biggest blogging software feature I’d suggest (other than the basics like RSS), is the ability for users to create their own accounts.

Holding Their Cards Close

Unless you’re working in an extremely dynamic, fresh-faced, Tom Peter’ed-up company, your co-workers aren’t going to be used to the concept of sharing information. Put another way, the idea of writing a blog post about what they’re working on, their ideas, or anything else is going to seem weird, foreign, and maybe even un-professional to your co-workers. People won’t post.

A small group of people, of course, will
“get it.”
So far, hoping for some sort of tipping point effect, I’ve just been trying to encourage and participate in the “discussions” that these people have: commenting on their posts, emailing them, or just talking to them in the hall. The corporate world is still in the early stages of the idea that blogging behind the firewall is natural and normal. Like I said, we’re probably not even at The Peak yet.

Hiding Out

On the flip-side of the adoption problem is the “oh shit, now people are actually going to read this!” problem. In the early, early stages of the blogging (when it was just me and 3-4 other people doing it), there was one person who posted very frequently, almost every day. But, as the blogs got more popular (when the executive sponsor sent an email to everyone in his department about them), that same person pretty much stopped posting.

They didn’t want to get in trouble for saying something.

I completely understand that. In any large organization, you have no idea who’s reading your stuff or what power they could wield to make your work-life difficult. It’s not quite that cynical of a situation, but, the point is, if you’re one of the only people posting, you realize how wide an audience you might have, and you start to get more cautious. Once more and more people start posting, creating more noise to “hide” in, this person will probably start posting more. I’m sure there are many other people in the company like that.

Too Much Noise

Another odd problem, considering the number of people posting, is that many readers have told me that there are too many posts from some people. For example, there are about 5-10 performance test status posts and news clippings posts a day. The front page of the blogs lists the most recent 10 (or 15?) posts, so it’s easy for those high frequency/quantity posts to cloud out others.

The solution to this is for readers to use aggregators: the can subscribe to feeds they’re interested in, and ignore the rest. Which brings up the next issue…

Aggregators Behind the Fire-wall

bloglines won’t work behind the fire-wall; and in it’s current state, you wouldn’t want it to. So, you have to find an alternative, which is pretty hard in the MS-Windows world. I’ve tried (in order) AmphetaDesk, SharpReader, Sage, and NewsGator Outlook Edition.

So far, I like the last one, NewsGator, the most: it integrates well with Outlook, it’s easy, and it doesn’t look weird. I’m trying to get the company to spring for some licenses, otherwise I might just buy one myself.

Sage is OK, but it’s not “independent” enough (you have to have Firefox’s history turned on, for example). SharpReader is actually a really good product, but I don’t like always having that separate application open. AmphetaDesk was just DOA for me.

As with any blazin’-hot technology, the problem with aggregators is getting people to know about them, and then use them. When I find the next slice of time, I’m going to use Camtasia (or whatever else) to record a screencast of installing and using NewsGator. I’ll put a link with big red letters on the main blogs page and hope people read it and think, “Ah-ha! That’s what I need!

There’s No Google Behind the Fire-wall

By far, the biggest problem with blogs behind the fire-wall is that there’s no Google behind the firewall. Without Google-quality search on your intranet (near real-time and full indexing, quick search results, page-rank, etc.), it’s extremely hard to find anything on the intranet let alone blog posts on relevant topics.

Search, from my seat, is a massive problem in the enterprise. If there’s one technology that indeed would make a difference to a company, it’d be getting good search behind the fire-wall. Companies have so much information on their intranets, but their employees can’t find any of it.

For the blogs, this means it’s hard to find posts and it’s harder to get discovered by people. Think of how many blogs or websites you’ve found when you’re searching for stuff in Google. That doesn’t happen on intranets: you have to know what you’re looking for, and where it is to “find” it.

My hope is to use Nutch to solve this problem. I’ve only had time to play around with it for a day, many months ago, but the results of that little proto-type were extremely positive. See below for another aspect of this problem when it comes to installing things like Nutch.

There is no Blog-o-sphere Behind the Fire-wall

The lack of good search behind the fire-wall is such a huge problem that I wanted to call it out on it’s own. But, it’s just a specific instance of a more abstract problem: all of the loosely coupled services “public” bloggers rely on don’t exist in the enterprise. There’s no Feedburner to keep track of your circulation; there’s no Flickr to easily host, share, and comment on pictures (diagrams) and other media; there’s no to keep track of bookmarks, and pursue other people’s bookmarks; there’s no Technorati, PubSub, or Feedster to connect together and surf through the blog-o-sphere.

You get the idea: there’s no services to help augment blogging.

Old Money Solutions

Companies like to spend thousands, if not millions, of dollars on the enterprise software they use. So, you might have sunk a ton of money into Vignette, and you’ve probably bought one of those enterprise licenses from Microsoft, so you’ve “paid for” SharePoint.

When all that money has been spent, it’s hard to all the sudden say, “oh, I guess we didn’t need to spend all that money…we can just install this (near) free software and get the same effect.” It looks bad, real bad, if you’ve convinced the purse-holder to part with some serious cash, and then you all the sudden decide you didn’t actually need to spend all that money.

So…when you suggest using blogs, you get answers like, “doesn’t SharePoint do that?” Or, “we’ve spent a lot of money of X already. Shouldn’t we use that?”

There’s really no way getting around this. You just have to install your blog system, and let it sell itself.


The most annoying problem so far has been the care and feeding of the blogs box. Like I said, I just installed it on an extra box I had in my office. The machine isn’t the strongest horse in the stable. Every now and then, the box crashes, and I have to restart it.

This’ll happen with any software, but at a company, you usually have people who make sure your enterprise applications are running smoothly, restarting them if needed. (Indeed, those are exactly the people my company makes software for.)

When you’re just skunk-working blogs on your own, you’re those people. You’re the one who’ll need to restart the box when it crashes.

Luckily for me, many of the people in my group are as enthusiastic about blogs as I am. They help out, a lot. So, when I went on a two week’s vacation, I got three of them to be the “blog nannies”: if the box went down, they’d go fix it. And, in fact, they had to reset the box once.

What About Your experiences?

I’ve been kicking these ideas around in my head for some time. Lots of the people you see in my blogroll have too. I’m hoping that by sharing them, I’ll get other people to share similar experiences with blogging behind the fire-wall.

As I was listening to that Gillmor Gang episode, I realized how much of the kool-aid I’d drank. Everything they said about enterprise blogging seemed old hand and taken-for-granted to me. Or, as Brandon‘s described this feeling before, “Yup. Welcome to the party.” I don’t really even feel like there’s a need to sell the idea anymore: it’s just self-evident that it’s a good idea.

Of course, like I said, I’ve had a whole trash-can, if not more, of the blogging kool-aid. And I had it a long, long time ago. I know all this isn’t obvious, or even true, for huge amounts of people.

So, what are your experiences with blogging behind the fire-wall? What are your thoughts on how effective/productive/good it is or could be? Does any of this even make sense?

Followup: see
my follow up post

Tags: , , , .

Tags: , , , .

RSS Security

The most recent Gillmor Gang touched on restricting access to RSS. Basic HTTP authentication can be used to lock out access to fetching the feed. That is, you can tell your web server (which provides the RSS feed to the world) not to allow access to the RSS feed unless the request authenticates with a username and password. If the username and password are incorrect, the user won’t be able to fetch the RSS feed.

Even though support for it isn’t in all aggregators (NewsGator has it, bloglines doesn’t. Though, you could encode the username and password in the URL.), that problem is solved, mas o menos.

Psuedo-DRM for RSS

The point that Steve O’Grady raised was a sort of DRM problem: making sure that once a user (or program) gets their hand on the RSS feed, that it doesn’t get redistributed to unauthorized parties. This is a huge problem, re: RSS security, in systems like bloglines and other “middle-men” of the RSS world.

Here’s the scenario:

  • You enter your secret RSS feed into bloglines. (Assuming that feature is available.)
  • bloglines goes out and fetches the secret RSS.
  • You can read your secret feed in bloglines.
  • A different user logs into bloglines and searches for “secret feed,” which finds your secret feed.
  • That user subscribes to your secret feed, and then your secret’s out!

Putting it in the Aggregator

Now, bloglines does have the ability to make a feed “private.” I’m not quite sure what that means as I’ve never used it, but I’d hope it mean that other users would never be able to “find” the feed. Maybe not though.

Anyway, by default it’s public. What if you, or someone else you want to access the secret feed, forgets to check off that “private” feature? Then your secret’s out again. Oh no!

Extending RSS

So, that’s the big scenario/problem. RSS being a very open and flexible data format (or de facto standard…I hesitate to call it a standard), we could easily fix this problem by just creating a security namespace, and inserting in a few tags that help describe the security restrictions for the feed. Something like:


Which would tell aggregations like bloglines “don’t share this with anyone else but the reader who subscribed to it.”

Encrypting Content

Another option would be to support encrypted messages, backed by something like PGP. The RSS’s “post” content would just be a big block of public-key encrypted text. So, when a user tried to read the post, the aggregator software would pop-up a prompt for the password/keys needed to decrypt the post.

I think that feature would be damn cool: then you could post everything publicly, and you’d be able to push down locking and unlocking to the edge (the publishing software and the aggregator), getting closer to a stupid network instead of relying on the network and it’s protocols to protect you. It’d also be good because your data would be protected even if the aggregator sucking in your RSS feed didn’t support this scheme: all the posts are encrypted, so unless your aggregator has support for decrypting them, they’ll be protected.

Good Luck Getting It Done

Of course, technically this is no big deal. The problem is getting the vendors in the blog/syndication/wiki world — Movable Type, blogger, bloglines, Technorati, etc. — to just start doing it.

Too bad I’m not in that world. It sure would be fun ;>

Tags: , , , , , .

Tags: , , , , , .