###A little bit of background I’ve worked with a lot of teams over the years both on-site with customers and in-house with independent teams and one of the constants was the need for a persistent knowledge archive.

“persistent knowledge archive” is just a pompous term for a repository where the team can easily maintain draft documentation, document decisions that affect development and also maintain documentation that is not actually part of the product, like how to use the testing rig, how to setup the development environment etc.

###Single point of reference One of the first things I ever introduced ¹ in our team workflow was the use of a wiki for exactly that purpose.

The previous alternatives of mass emails and (gasp) Word documents were just too transient or cumbersome.

There are several reasons for that, but the most important in my mind is that a wiki (and a blog) provides a single point of reference that is easy to edit and keep current and has a very easy learning curve.

When you get new team members you just point them to the URL and give a little speech about the project conventions and you’re done.

###Scope I’m going to narrow a bit the scope for this article in order to get my point across.

We’re talking about wikis vs. blogs as tools for team communication, information dissemination that demands the least amount of maintenance and ensures that the information persists and is accessible at any point in the future.

While I have for a long time advocated the use of wikis for my teams, recently I have substituted the wiki for a blog and this is an attempt to explain and discuss the pros and cons of this decision.

But first a couple of definitions

###Wiki Google “wiki definition” and you get

wi·ki /ˈwikē/
Noun: A Web site developed collaboratively by a community of users, allowing any user to add and edit content.

I our scope the community is the team developing the software

###Blog Google “blog definition” and you’ll get

blog /blôg/
Noun: A Web site on which an individual or group of users record opinions, information, etc. on a regular basis. 

Again in our scope the group of users is the team and everyone on the team can add and edit posts. ###Wiki vs. Blog Technically there is no substantial difference between a wiki and a blog in the scope we have just defined. Both are essentially content management systems that allow their users to create and edit content.

For both types there is software that provides versioning facilities, search, commenting, file uploads and notifications for new content. So, no difference there.

The experiment of substituting the wiki with a blog showed that there are small but significant differences on the usage uptake between the two tools.

My recent experience showed that a blog was more easily accepted and started seeing use by the team a lot faster than a wiki. There seemed to be more incentive in adding to the blog than in adding to the wiki.

Now the evidence is empirical and also there are significant differences between projects for there to be a definite verdict but the indications are nonetheless strong.

One reason for it might be that the blog format is by now very familiar to the overwhelming majority of software developers. Many of my colleagues maintain their own blogs and have no difficulties with the concept.

I find this hard to believe though. Most blog engines use text markup that originated with wikis (Markdown, Textile etc.) and as I already said there is hardly any difference in how content is created or updated.

I attribute the difference to the concept of content ownership: In a wiki a single page has no clear owner. It’s a collaborative effort by definition and that ever present edit button seems to scare some people off². Editing something someone else wrote feels I guess invasive.

In the blog the pattern of usage has a clear ownership attribute: the post is owned by whoever created it, any discussion about the content happens in the comments section and there is the implicit understanding that any changes needed to keep the content current will be undertaken by the content owner.

Now this is a purely psychological difference, since on both platforms everyone on the team can view and edit everything, but the empirical evidence suggests it is significant.

There is one usage for which wikis are undisputedly the better solution and that is for collaboratively developing the official project documentation but there the “ownership” of the content is explicitly shared which to my mind strengthens the argument.

In the case of official documentation we can also view it as a single unit of structured work where the interlinking facilities of a wiki are a huge advantage and impose a kind of unification layer while in a blog each post is a single unit and does not necessarily have to fit with everything else, which makes it ideal for informal information dissemination.

###Recap I find that blogs make a better communication medium for medium to long term persistence of project relevant knowledge (design decisions, howtos, status reports) while wikis are much better for developing official documentation. Transient information (“yoohoo, new version for our favorite library”) is still best handled through IM and emails.

Feel free to flame me as an ignorant idiot.

¹ “introduce” is another pompous term that means I ran around extolling the virtues of a tool until my significantly more intelligent colleagues get tired of hearing the noise and start using it just to shut me up.

² I initially was myself baffled by this since collective code ownership is something we strive for in our projects until I noticed that no matter how many developers can understand and change the code the developer who originally was tasked with creating a feature was always referred to as “the guy who wrote it”.