<?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: Adding Manpower</title>
	<atom:link href="http://kosmaczewski.net/2008/08/08/adding-manpower/feed/" rel="self" type="application/rss+xml" />
	<link>http://kosmaczewski.net/2008/08/08/adding-manpower/</link>
	<description>sin incertidumbre no hay novedad, sin novedad posible no hay más que repetición y, por lo tanto, negación del otro como un ser libre: el ser libre es un ser incierto. (adrian mancuso)</description>
	<lastBuildDate>Mon, 15 Mar 2010 09:02:30 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Martin Miller</title>
		<link>http://kosmaczewski.net/2008/08/08/adding-manpower/comment-page-1/#comment-27617</link>
		<dc:creator>Martin Miller</dc:creator>
		<pubDate>Tue, 20 Oct 2009 01:32:38 +0000</pubDate>
		<guid isPermaLink="false">http://kosmaczewski.net/?p=1247#comment-27617</guid>
		<description>Here&#039;s part of comment that I made recently to an online Wall Street Journal article titled &quot;To Rebuild Windows, Microsoft Razed Walls&quot; where  in a nutshell they said that Microsoft claimed Windows 7 was going to be a whole lot better than Vista because of all the communication that was now going within the company that wasn&#039;t there for Vista&#039;s development (which is largely regarded as a failed release):


As a software developer with over 30-years of experience, I am extremely skeptical about any claims that getting more people communicating with each other will really solve the problems that existed with Vista. The is a common management misconception. In the book titled &quot;The Mythical Man-Month: Essays on Software Engineering&quot; by Fred Brooks, originally published in 1975, it was also claimed that to avoid disasters, all the teams working on a project should remain in contact with each other in as many ways as possible.

Sorry, that&#039;s simply not true. The more lines of communications there are, the more overhead there is, the more time is spent in transmitting and managing all the information. It&#039;s basically a problem in combinatorial mathematics. The number of lines of communication between pairs of people increases very rapidly (ie factorially) as you add additional personnel, and can quickly get out of hand.


I mention this because the what is written here in both the main entry and other comments is about *adding* manpower to a project, where what I speak to simply that of having the people already on the project start &quot;communicationing&quot;. This slight difference is fairly important I think, and I&#039;d like to hear other&#039;s thoughts.

--
Martin

P.S. The Wall Street Journal article can be found here:
</description>
		<content:encoded><![CDATA[<p>Here&#8217;s part of comment that I made recently to an online Wall Street Journal article titled &#8220;To Rebuild Windows, Microsoft Razed Walls&#8221; where  in a nutshell they said that Microsoft claimed Windows 7 was going to be a whole lot better than Vista because of all the communication that was now going within the company that wasn&#8217;t there for Vista&#8217;s development (which is largely regarded as a failed release):</p>
<p>As a software developer with over 30-years of experience, I am extremely skeptical about any claims that getting more people communicating with each other will really solve the problems that existed with Vista. The is a common management misconception. In the book titled &#8220;The Mythical Man-Month: Essays on Software Engineering&#8221; by Fred Brooks, originally published in 1975, it was also claimed that to avoid disasters, all the teams working on a project should remain in contact with each other in as many ways as possible.</p>
<p>Sorry, that&#8217;s simply not true. The more lines of communications there are, the more overhead there is, the more time is spent in transmitting and managing all the information. It&#8217;s basically a problem in combinatorial mathematics. The number of lines of communication between pairs of people increases very rapidly (ie factorially) as you add additional personnel, and can quickly get out of hand.</p>
<p>I mention this because the what is written here in both the main entry and other comments is about *adding* manpower to a project, where what I speak to simply that of having the people already on the project start &#8220;communicationing&#8221;. This slight difference is fairly important I think, and I&#8217;d like to hear other&#8217;s thoughts.</p>
<p>&#8211;<br />
Martin</p>
<p>P.S. The Wall Street Journal article can be found here:</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pierre De Pascale</title>
		<link>http://kosmaczewski.net/2008/08/08/adding-manpower/comment-page-1/#comment-19986</link>
		<dc:creator>Pierre De Pascale</dc:creator>
		<pubDate>Mon, 11 Aug 2008 09:03:21 +0000</pubDate>
		<guid isPermaLink="false">http://kosmaczewski.net/?p=1247#comment-19986</guid>
		<description>Brooks Law when taken too literally freezes your project. The Manpower on a software project follows a kind of bell curve. So at one point you will add some people to the project. It is inevitable. If you don&#039;t, because &quot;hey adding more people to a late project, only makes it later&quot;, you won&#039;t be able to deliver.

In fact you&#039;ll notice that a team may absorb some more people without too much burden and still be productive. Beyond a certain limit, Brooks law comes really into play.

Note that the converse is also bad. When too many people are leaving a project, the know-how deficit becomes too high and you won&#039;t be able to maintain the project afloat. I don&#039;t know the name of this law though. Someone ?</description>
		<content:encoded><![CDATA[<p>Brooks Law when taken too literally freezes your project. The Manpower on a software project follows a kind of bell curve. So at one point you will add some people to the project. It is inevitable. If you don&#8217;t, because &#8220;hey adding more people to a late project, only makes it later&#8221;, you won&#8217;t be able to deliver.</p>
<p>In fact you&#8217;ll notice that a team may absorb some more people without too much burden and still be productive. Beyond a certain limit, Brooks law comes really into play.</p>
<p>Note that the converse is also bad. When too many people are leaving a project, the know-how deficit becomes too high and you won&#8217;t be able to maintain the project afloat. I don&#8217;t know the name of this law though. Someone ?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
