The Old New Thing

Speaking as a part-owner of a company that specialises in web content management software, I can only say one thing: if only our customers would realise this, instead of expecting us to fix _all_ of their problems, life would be so much easier.

Just define 'it' as 'actual content' and you're set. :-)

I must disagree to some extent. Back in the day I'd fire up vi to edit a page on my server. Of course I really never had much to say. But I had a server and could use vi.

But look what happened when blog software appeared? Suddenly people who did have something to say had an easy way to say it.

Touche.  (In regards to my comment about yesterday's post).

Excellent point.  Good content in a reasonably accessable way will get you lots of readers.  (Some big company has content that's not easily accessible--and it's a selling point for their service.)

I've heard some managers or the like say that "all we need to do is create a wiki, and all our in-house tools will be documented." Same principle, I suspect. Good content won't magically happen, even if barriers to creating it lessen.

Good points, and good pair of posts. If only more managers from all lines of business paid attention to such advice.

I would like to point out, however, that in the example situation described there is a deficient process and unpublished content. The trick lies in identifying existing processes and infrastructure that would serve the purpose.

It's easy to scoff at the buzzwords, but it's not like "processes" and "infrastructure" are inherantly useless. These words have attained the status they have by meaning something useful.

Good one, Nathan!  

Creating an in-house wiki doesn't cause documentation to happen unless somebody actually has time (or has been ordered to magically find time) to write documentation.  

I'd imagine that, when faced with getting Project X done or having the engineers tied up trying to document Project X (or explain Project X well enough so it can be documented by somebody else), most managers will favor finishing the project and forget about documentation until somebody raises a fuss.

Thanks Raymond. My CTO needs to read this so much that I will have to forward it anonymously.

+1 to Nathan.

Just a couple of days ago I found a technical documentation page on a corporate wiki which said, in its entirety, "I don't really understand this. Maybe somebody else could edit this page and add some useful information?" :-)

[You have a "they" (people who had something to say).]

Ah, now the title makes more sense.  I was thinking you meant that "they" were the people that would read the content that got put into whatever process.  You meant the people that would create the content.

It makes sense the way you put it (where "they" is the people that create the content); it's just not what I expected when I heard the saying.  But I get it now.  :-)

Seems to me this is too often a chicken or egg thing.  Rush to build a site to display content that isn't available anyway or rush to hack together a site to display content that's been ready and waiting with no means of sharing it.

There is one good reason to build (as a company) a site for your users to exchange content. That sign is that your users are trying to do so themselves.

If they're good developers, skip the first steps of your own internal plans and just hire those guys outright. If not, but they still manage to build a community, at least buy their community and give them some official status.

As far as the build a tool thing goes, you can always make a display widget that shows whether any high priority bugs are open on the operational bug DB (assuming you have one). I favor automatic solutions like this one - low maintenance and allows people to see when something is busted.