Re: hosers-talk: Fred Brooks, Turing Award Winner

["Jon Stewart" <stew1@xxxxxxxxxxx>]

> So, why can the software process be so crappy? 


If you have to ask...

The book tries to answer, in part, how not to make the software process so 
crappy. It's somewhat assumed that the reader is all-too-familiar with why 
it can be that way.


> And why is a "man month" 
> mythical?


And I quote, from chapter 2:

"The second fallacious thought mode is expressed in the very unit of 
effort used in estimating and scheduling: the man-month. Cost does indeed 
vary as the product of the number of men and the number of months. 
Progress does not. <I>Hence the man-month as a unit for measuring the size 
of a job is a dangerous and deceptive myth.</I> It implies that men and 
months are interchangeable.

Men and months are interchangeable commodities only when a task can be 
partioned among many workers <I>with no communication among them</I>. This 
is true of reaping wheat or picking cotton; it is not even approximately 
true of systems programming. 
	
When a task cannot be partioned because of sequential constraints, the 
application of more effort has no effect on the schedule. The bearing of a 
child takes nine months, no matter how many women are assigned. Many 
software tasks have this characteristic because of the sequential nature 
of debugging.

In tasks that can be partioned but which require communication among the 
subtasks, the effort of communication must be added to the amount of work 
to be done. Therefore the best that can be done is somewhat poorer than an 
even trade of men for months.

The added burden of communication is made up of two parts, training and 
intercommunication. Each worker must be trained in the technology, the 
goals of the effort, the overall strategy, and the plan of work. This 
training cannot be partioned, so this part of the added effort varies 
linearly with the number of workers.

Intercommunication is worse. If each part of the task must be separately 
coordinated with each other part, the effort increases as n(n-1)/2. Three 
workers require three times as much pairwise communication as two; four 
requires six times as much as two. If, moreover, there need to be 
conferences among three, four, etc., workers to resolve things jointly, 
matters may get worse yet. The added effort of communicating may fully 
counteract the division of the original task and brings us to the 
situation of Fig. 2.4 [a simple graph of a quadratic in quadrant I -- 
months as Y, and men as X -- more men may give you some more time, but you 
reach an inflection point somewhere, and then more men take more time -- 
Jon].

Since software construction is inherently a systems effort -- an exercise 
in complex interrelationships -- communication effort is great, and it 
quickly dominates the decrease in individual task time brought about by 
partioning. Adding more men then lengthens, not shortens, the schedule.

...[skip a number of paragraphs, giving cases and examples and going into 
debugging and testing, the two most delayed parts of the software 
process, to the end of the chapter]...

Oversimplifying outrageously, we state Brooks's Law:

	<I>Adding manpower to a late software project makes it later.</I>

This then is the demythologizing of the man-month. The number of months of 
a project depends upon its sequential constraints. The maximum number of 
men depends upon the number of independent subtasks. From these two 
quantities one can derive schedules using fewer men and more months. (The 
only risk is product obsolescence.) One cannot, however, get workable 
schedules using more men and fewer months. More software projects have 
gone awry for lack of calendar time than for all other causes combined."



It's very much like issues in parallel programming, where tasks which 
cannot be partioned are no damn good, and tasks which can be somewhat 
partioned depend greatly upon having a really fast network.



Jon
-- 
Jon Stewart
stew1@xxxxxxxxxxx

"Survey says: it was a bad idea in the first place."

	-- The Dismemberment Plan