The Enid Blyton effect

Wiki worries

An architect's role often includes defining the use of development tools and process.

One such tool which I value greatly is a wiki.

For those of us used to developing with an in-team wiki, it's very hard to imagine not using one. Of course, there are many different knowledge sharing systems which can do the same job, but a few months ago I joined a team which, not only had no wiki, but had no adequate replacement: a collection of documents scattered across an online drive, email folders, source control, and individual hard-disks not only lacked structure, but lacked the low-level detail of changeable information which is vital knowledge for members of the development team.

After championing the introduction of a wiki, I was pleased to see it in active use by the team. It had become a vital resource for new joiners and was used as a continual reference, with almost every team member having added useful pages.

However I quickly noticed what I call an Enid Blyton effect creeping in. Some developers' suppressed desires to be authors surreptitiously surfaced, and I noticed reams of borderline-relevant material being posted. For example, a developer would create a page on an obscure business topic which he was far from an authority on, and yet never get round to posting key configuration parameters about a particular build process he had improved. Some of the more obscure features of the particular wiki implementation -- polls, graphs, emoticons -- were explored at length, but added no useful information. Deep hierarchies of structure were introduced, presumably on the assumption that the author would come back later to flesh out an enormous topic, but with the end result of simply hiding any useful content behind 7 pages which needed to be clicked-through.

There was a concern that in trying to improve communication in the team, I had simply distracted developers from productive output by giving them a new toy with little guidance.

The battle for Wikipedia's soul story in this week's issue of The Economist outlines a similar problem facing Wikipedia contributors: how do you censor the content of a wiki so as to keep it relevant, without suppressing the enthusiasm of the contributors? The rather more dour terms of inclusionists versus deletionists were used.

My experience in this case was to err on the inclusionist side. Remove superfluous structure where necessary, but generally let people put up anything which they think relevant. The initial spike of extraneous content leveled off, and the overall relevance level remained high.

My own instincts are still to post to a wiki, even if it's just a personal page, rather than writing down information in a log book which I think I might need later. Like they say, you can't grep dead trees.

About the author

Kenneth RoperKenneth Roper is a development team leader at tier-1 investment bank. He is interested in applications with low-latency requirements or large memory footprints. He spends a lot of time reading garbage collection logs and snow reports.

E-mail : kenneth.roper at

Re: The Enid Blyton effect

Likening your own concern for quality with the reported megalomania of some of Wikipedia's inner clique seems a bit far-fetched. For starters, it's hard to imagine that there's much to be gained from skewing a particularly topical page on your wiki! However, the coverage of Wikipedia does serve up some interesting questions about how information should be managed in such a collaborative medium. Who is right? Who decides they are right? How do you prevent a vocal minority skewing the process?

In a word: you! Collaborative techniques are not plug-and-play solutions - they take time (and often considerable effort) to adopt. Until the team is self-managing you'll have to manage them - and that might have to be quite strictly to avoid bad habits forming. It's not democratic, it's possibly not even meritocratic, but it'll get there eventually.

That said, I'm a fan of freedom of expression, whether it's in wiki entries or code commentary. While you might argue that an off-topic entry is a potential maintenance risk it would have to be weighed against the potential for stifling enthusiasm. I'd be more worried about the use of a survey plugin on a wiki of this nature. At best it shows a naive view of statistics and response rates! At worst it may indicate someone who can't interact with the team more directly. It's probably just a bit of tyre-kicking, though.

In my experience these things tend to iron themselves out over time. Whenever an opportunity presents itself you instruct someone to "put it on the wiki". Concise, relevant content will increase. Irrelevant content will be sidelined - whether you choose to remove it is perhaps academic at that point.

Re: The Enid Blyton effect

I stand by my wikipedia comparison: the volume of information is different, the size of the egos is perhaps a moot point :-). The editorial balance between promoting relevance and promoting enthusiasm remains.

(On that note, the irony of a technologist damning other technologist's latent desires to be authors, on a blog, has not escaped me.)

You make an excellent point about collaborative techniques needing effort to adopt. Even in teams which have (sometimes several!) well-integrated wikis, I have often heard the knee-jerk reply of "it's on the wiki" to questions which only require a 10 second answer themselves. A wiki should not be used by experienced members to make other team members feel like they haven't done their homework, simply because they have not memorised every word on the site. Nor should they be used as a tool to dump all their knowledge so that they never need to talk to another human again. Rather the focus should remain on using the wiki as a complement to overall effective communication across the team.

Add a comment Send a TrackBack