<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - wiki tag</title>
  <link>http://www.codingthearchitecture.com/tags/wiki/</link>
  <description>Software architecture for developers</description>
  <language>en</language>
  <copyright>Coding the Architecture</copyright>
  <lastBuildDate>Mon, 21 May 2012 09:41:00 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>The Enid Blyton effect</title>
    <link>http://www.codingthearchitecture.com/2008/03/12/the_enid_blyton_effect.html</link>
    
      
        <description>
          &lt;p&gt;

An architect&#039;s &lt;a href=&#034;http://www.codingthearchitecture.com/2007/07/31/role_profile_for_software_architects.html&#034;&gt;role&lt;/a&gt; often includes defining the use of development tools and process.
&lt;/p&gt;&lt;p&gt;
One such tool which I value greatly is a wiki.
&lt;/p&gt;&lt;p&gt;
For those of us used to developing with an in-team wiki, it&#039;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.
&lt;/p&gt;&lt;p&gt;

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.
&lt;/p&gt;&lt;p&gt;

However I quickly noticed what I call an &lt;a href=&#034;http://en.wikipedia.org/wiki/Enid_blyton&#034;&gt;Enid Blyton&lt;/a&gt; effect creeping in.  Some developers&#039; 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.
&lt;/p&gt;&lt;p&gt;

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.
&lt;/p&gt;&lt;p&gt;

&lt;a href=&#034;http://www.economist.com/printedition/displaystory.cfm?story_id=10789354&#034;&gt;The battle for Wikipedia&#039;s soul&lt;/a&gt; story in this week&#039;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.
&lt;/p&gt;&lt;p&gt;

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.
&lt;/p&gt;&lt;p&gt;
My own instincts are still to post to a wiki, even if it&#039;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&#039;t grep dead trees.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>How do you share software architecture?</category>
    
    <comments>http://www.codingthearchitecture.com/2008/03/12/the_enid_blyton_effect.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2008/03/12/the_enid_blyton_effect.html</guid>
    <pubDate>Wed, 12 Mar 2008 19:30:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>

