<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Conway&#8217;s law</title>
	<atom:link href="http://blog.kriskemper.com/2008/08/03/conways-law/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.kriskemper.com/2008/08/03/conways-law/</link>
	<description>Thoughtworker, Agile Philosopher, Hero</description>
	<lastBuildDate>Sun, 11 Sep 2011 04:15:23 -0700</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: Ignas</title>
		<link>http://blog.kriskemper.com/2008/08/03/conways-law/comment-page-1/#comment-210</link>
		<dc:creator>Ignas</dc:creator>
		<pubDate>Mon, 04 Aug 2008 13:01:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kriskemper.com/2008/08/03/conways-law/#comment-210</guid>
		<description>I have noticed this on a piece of software that I am working on. As soon as we have switched the way project is being managed, the code and the architecture started slowly drifting towards the new organizational structure.

My best guess is that different modules of the system get organized along the pathways of communication, compartmentalization happens wherever there is a bottleneck, and close integration naturally appears when you have the same team working on both components at the same time.

Having the same module developed by 2 teams that are on different sides of the ocean requires much more effort. So conservation of effort drives the project towards having 2 modules with well defined interfaces and are stable enough to keep required coordination down.</description>
		<content:encoded><![CDATA[<p>I have noticed this on a piece of software that I am working on. As soon as we have switched the way project is being managed, the code and the architecture started slowly drifting towards the new organizational structure.</p>
<p>My best guess is that different modules of the system get organized along the pathways of communication, compartmentalization happens wherever there is a bottleneck, and close integration naturally appears when you have the same team working on both components at the same time.</p>
<p>Having the same module developed by 2 teams that are on different sides of the ocean requires much more effort. So conservation of effort drives the project towards having 2 modules with well defined interfaces and are stable enough to keep required coordination down.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Domingos Neto</title>
		<link>http://blog.kriskemper.com/2008/08/03/conways-law/comment-page-1/#comment-205</link>
		<dc:creator>Domingos Neto</dc:creator>
		<pubDate>Sun, 03 Aug 2008 23:56:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.kriskemper.com/2008/08/03/conways-law/#comment-205</guid>
		<description>Hi,

Intriguing.  I would expect to see the unstructured organization to have unstructured code.  I would also have a compartmented organization to have compartmented software.  But the manufacturing company thing blew my mind.

But I like your theory, and I think it may very well be the cause for this to happen.</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>Intriguing.  I would expect to see the unstructured organization to have unstructured code.  I would also have a compartmented organization to have compartmented software.  But the manufacturing company thing blew my mind.</p>
<p>But I like your theory, and I think it may very well be the cause for this to happen.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

