Mito Hombre Mes

7/30/2019 Mito Hombre Mes

1/17

El mtico hombre-mes

La buena cocina falsificaciones tiempo. Si se hacen esperar, es para

servir mejor, y para complacer a usted.

Ms proyectos de software han ido mal por falta de tiempo del

calendario que para todas las otras causas combinadas. Por qu escausa de este desastre tan comn?

En primer lugar, nuestras tcnicas de estimacin estn poco

desarrollados. Ms en serio, que reflejan un unvoiced supuesto que es

bastante falso, es decir, que todo vaya bien.

En segundo lugar, nuestra estimacin de las tcnicas de fallaciously

confundir esfuerzo con el progreso, ocultando el supuesto de que los

hombres y los meses son intercambiables.

En tercer lugar, porque estamos seguros de nuestras estimaciones, el

software a menudo carecen de los administradores de la cortesa de

la terquedad de Antoine Chef.En cuarto lugar, el progreso es mal horario de seguimiento. Tcnicas

de rutina y probado en otras disciplinas de la ingeniera se consideran

innovaciones radicales en la ingeniera de software.

En quinto lugar, cuando el deslizamiento es reconocido calendario, la

naturaleza (y tradicional) es la respuesta para aadir mano de obra.

Dousing como un fuego con gasolina, lo que es peor, mucho peor.

Ms fuego requiere ms gasolina, y, por tanto, comienza un ciclo

regenerativo que termina en desastre.

Calendario de seguimiento sern objeto de un ensayo. Vamos a

considerar otros aspectos del problema con ms detalle.Todos los programadores de optimismo son optimistas. Tal vez este

moderno brujera atrae especialmente a los que creen en las hadas y

los finales felices dios madres. Tal vez los cientos de nitty

frustraciones en coche, pero todos los que habitualmente se centran

en el objetivo final.

Quizs es simplemente que las computadoras son jvenes, los

programadores son ms jvenes y los jvenes son siempre

optimistas. Pero sin embargo, el proceso de seleccin de las obras, el

resultado es indiscutible: "Esta vez seguramente plazo," o "Acabo de

encontrar el ltimo error."As, el primer falso supuesto de que la base de la programacin de

sistemas de programacin es que todos van bien, es decir, cada tarea

que se alza slo en la medida en que "debe" adoptar.

La omnipresencia de optimismo entre los programadores, merece

ms que una tapa de anlisis. Dorothy Sayers, en su excelente libro,

La Mente del Creador, la actividad creativa se divide en tres etapas:

la idea, la ejecucin, y la interaccin. Un

libro, entonces, o un ordenador, o un programa entra en existencia en

primer lugar como la construccin de un ideal, construido fuera detiempo y espacio, pero completo en la mente del autor. Que se


2/17

realiza en tiempo y espacio, por la pluma, tinta y papel, o por cable,

el silicio,

y ferrita. La creacin se completa cuando alguien lee el libro, utiliza el

ordenador, o ejecuta el programa, con lo que interactan con la

mente del fabricante.

Esta descripcin, que la Srta. Sayers utiliza para iluminar no slo laactividad creativa humana, sino tambin la doctrina cristiana de la

Trinidad, nos ayudar en nuestra tarea. Para los encargados de la

persona humana de las cosas, la incompletenesses e incoherencias

de nuestras ideas quedado claro slo durante la ejecucin. Por lo

tanto, es que la escritura, la experimentacin, la "elaboracin" las

disciplinas son esenciales para el terico.

Muchas actividades creativas en el medio de ejecucin es de difcil

solucin. Divisiones de madera, pinturas de Papanicolau; anillo de

circuitos elctricos. Estas limitaciones fsicas del medio limitan las

ideas que pueden expresarse, y tambin crear dificultadesimprevistas en la aplicacin.

La aplicacin, entonces, lleva tiempo y sudor, tanto por las

caractersticas fsicas y los medios de comunicacin a causa de las

deficiencias de las ideas. Tendemos a culpar a los medios fsicos para

la mayora de nuestras dificultades de aplicacin, por los medios de

comunicacin no son "los nuestros" en la forma en que las ideas son

nuestro orgullo y nuestro juicio colores.

Programacin de computadoras, sin embargo, crea un medio muy

manejable. El programador construye a partir de la reflexin pura

cosas: los conceptos y las representaciones de stos, muy flexible.Debido a que el medio es manejable, esperamos algunas dificultades

en la aplicacin; de ah nuestro optimismo generalizado.

Porque nuestras ideas son defectuosos, tenemos errores, por lo tanto,

nuestro optimismo no se justifica.

En una sola tarea, la hiptesis de que todo ir bien probabilstica

tiene un efecto en el calendario. Es posible que tenga que ir de all es

una distribucin de probabilidad de que el retraso

se ha tropezado, y "no hay retraso" tiene una probabilidad finita. Un

gran esfuerzo de programacin, sin embargo, se compone de muchas

tareas, algunas de cadena de extremo a extremo. La probabilidad deque cada uno vaya se convierte as vanishingly pequeo.

El segundo modo de pensamiento falaz se expresa en la unidad de

esfuerzo muy utilizadas en la estimacin y la programacin: el

hombre-mes. De hecho, varan los costos, como producto del nmero

de hombres y el nmero de meses. Progreso no. Por lo tanto, el

hombre-mes como

unidad para medir el tamao de un puesto de trabajo es un mito

peligroso y engaoso. Implica que los hombres y los meses son

intercambiables.Los hombres y los meses son intercambiables cuando las mercancas


3/17

slo una tarea puede ser dividida entre muchos trabajadores sin

comunicacin entre ellos (Fig. 2.1). Este es el caso de cosechar el

trigo o la recoleccin de algodn, sino que ni siquiera es cierto en el

caso de unos sistemas de programacin.

HombresFig. Tiempo frente a 2,1 el nmero de trabajadores-tarea

perfectamente partitionable El Hombre-Mes

Cuando una tarea no puede ser dividido a causa de las limitaciones

de la secuencia, la aplicacin de un mayor esfuerzo no tiene ningn

efecto sobre el calendario (Fig. 2.2). La portacin de un nio tiene

nueve meses, no importa cmo muchas mujeres se les asigna.

Muchos programas de tareas

esta caracterstica, debido a la naturaleza secuencial de la

depuracin.

Fig. Tiempo frente a 2,2 el nmero de trabajadores-en tareas

unpartitionable tarea que puede ser dividido, pero que requieren la

comunicacin entre las subtareas, el esfuerzo de comunicacin debe

ser

aadir a la cantidad de trabajo por hacer. Por lo tanto, la mejor que

se puede hacer es un poco ms pobres que incluso el comercio de los

hombres durante meses (Fig. 2.3).

Hombres

Fig. Tiempo frente a 2,3 el nmero de trabajadores partitionable tareaque requiere la comunicacin

La carga aadida de la comunicacin se compone de dos partes, la

formacin y la intercomunicacin. Cada trabajador debe ser

capacitado en la tecnologa, los objetivos de la iniciativa, la estrategia

global,

y el plan de trabajo. Esta formacin no puede ser dividida, por lo que

esta parte del esfuerzo aadido vara linealmente con el nmero de

workers.1

Interior es peor. Si cada parte de la tarea debe sercoordinado por separado con cada uno de otra / aumenta el esfuerzo

como n (n-I) / 2. Tres trabajadores requieren tres veces ms

pairwise intercomunicacin de dos, cuatro, seis veces requieren

como

dos como mucho. Si, adems, es necesario que existan entre

conferencias

tres, cuatro, etc, de los trabajadores para resolver las cosas en

conjunto, las cuestiones obtener

peor an. El esfuerzo aadido de comunicacin pueda cumplir

plenamente contrarrestarla divisin de la tarea original y que nos llev a la situacin


4/17

de la fig. 2.4.

Hombres

Fig. Tiempo frente a 2,4 el nmero de trabajadores con tareas

complejas interrelaciones Desde la construccin de software de

sistemas es inherentemente un esfuerzoejercicio de complejas relaciones de comunicacin es un gran

esfuerzo, y rpidamente se domina la disminucin de la tarea cada

vez provocada por el particionado. Aadiendo a continuacin, se

alarga ms hombres, no se acorta, el calendario.

Sistemas de Prueba

Ninguna parte del calendario de fondo son tan afectados por las

limitaciones secuencial como componente del sistema de depuracin

y prueba.

Adems, el tiempo necesario depende del nmero y la sutileza de los

errores encontrados. En teora, este nmero debe ser cero. A causade optimismo, por lo general esperan que el nmero de errores al ser

menor de lo que resulta ser. Por tanto

la prueba es normalmente la ms misscheduled parte de la

programacin.

Durante algunos aos he estado utilizando con xito la siguiente

regla de oro para la programacin de un software de tarea:

l / 3 de planificacin

l / 6 de codificacin

l / 4 componentes y principios del sistema de prueba de ensayo

l / 4 sistema de ensayo, todos los componentes en la mano.

Esto difiere de la programacin convencional de varias maneras

importantes:

1. La fraccin dedicada a la planificacin es ms grande que lo

normal. Aun as, es apenas suficiente para producir una

especificacin detallada y slida, y no lo suficiente para incluir la

investigacin o de exploracin totalmente nueva techniques.2. La

mitad de la programacin dedicada a la depuracin de cdigo

completado es mucho mayor de lo normal.

3. La parte que es fcil de estimar, es decir, la codificacin, es slouna sexta parte de la programacin.

Convencionalmente en el examen de los proyectos programados, he

encontrado pocos que permite la mitad del calendario previsto para

la prueba, pero que la mayora de hecho, pasan la mitad de la

programacin para

ese fin. Muchos de estos fueron en el plazo previsto hasta el sistema

y, salvo en testing.2

El hecho de no permitir suficiente tiempo para probar el sistema, en

particular, su naturaleza es desastroso. Dado que la demora seproduce al final de la lista, nadie es consciente de la dificultad para


5/17

programar hasta casi la fecha de entrega. Mala noticia, tarde y sin

previo aviso, es inquietante para los clientes y al personal directivo.

Adems, la demora en este punto ha inusualmente graves

restricciones financieras, as como psicolgica, Repercusiones. El

proyecto es todo el personal, y el coste por da es la mxima. Ms en

serio, el programa es apoyar los esfuerzos de otros negocios (deenvo de las computadoras, el funcionamiento de nuevas

instalaciones, etc) y la demora de los costes secundarios-cin son

muy elevados, ya que es casi la hora de entrega de software.

De hecho, estos costos pueden secundaria son muy superiores a

todos los dems. Por lo tanto, es muy importante para permitir

suficiente tiempo de prueba del sistema en el programa original.

Estimacin de Gutless Observe que para el programador, como para

el cocinero, la urgencia de la patrona programadas pueden regir la

realizacin de la tarea, pero no puede gobernar la finalizacin. Una

tortilla, prometido en dos minutos, puede parecer que se avanza muybien. Pero cuando no se ha fijado en dos minutos, el cliente tiene dos

opciones, esperar o comerlo crudo. Software de los clientes han

tenido las mismas opciones.

El cocinero tiene otra opcin, que puede convertir el calor.

El resultado es a menudo una tortilla quemada nada puede guardar

en una parte, en otro crudo.

Ahora no creo que los administradores de programas tienen menos

valor inherente y la firmeza de los cocineros, ni que otros directivos

de ingeniera hombre. Pero falsa programacin para que coincida con

el patrn de la fecha deseadaes mucho ms comn en nuestra disciplina que en el resto de la

ingeniera. Es muy difcil hacer un vigoroso, verosmil, y de puestos

de trabajo en riesgo la defensa de una estimacin que se deriva de

ningn mtodo cuantitativo, con el apoyo de pocos datos, y

certificadas por el corazonadas principalmente de los directivos.

Es evidente que dos soluciones son necesarias. Tenemos que

desarrollar y dar a conocer las cifras de productividad, las cifras de

incidencia de errores, la estimacin de reglas, y as sucesivamente.

La profesin en su conjunto slo pueden beneficiarse de compartir

esos datos.Hasta la estimacin se encuentra en una base ms slida, los

administradores tendrn que endurecer sus troncales y defender sus

estimaciones con la garanta de que sus malas corazonadas son

mejores

que las estimaciones derivadas de deseos.

Calendario de los Desastres Regenerativa Qu hace uno cuando un

proyecto de software est detrs

horario? Aadir la mano de obra, naturalmente. Como Figs. 2.1 a 2.4

sugerir, esto puede o no ayudar.

Veamos un example.3 Supongamos que una tarea se estima en 12meses-hombre y se asign a tres hombres por cuatro meses, y que


6/17

no son mensurables mileposts A, B, C, D, que est previsto que al

final de cada mes (Fig. 2.5).

Ahora supongamos que el primer hito no se alcanza hasta que hayan

transcurrido dos meses (Fig. 2.6). Cules son las alternativas que

enfrenta el gerente?

1. Supongamos que la tarea debe hacerse a tiempo. Supongamos queslo la primera parte de la tarea fue misestimated, por lo que la fig.

2,6 narra la historia con precisin. Entonces 9 meses-hombre de

esfuerzo siguen siendo, y dos meses, a fin de 4V hombres sern

necesarios. Aadir 2 a los 3 hombres asignado.

2. Supongamos que la tarea debe hacerse a tiempo. Supongamos que

toda la estimacin se baja de manera uniforme, de modo que la fig.

2,7

realmente se describe la situacin. Luego 18 meses-hombre de

esfuerzo siguen siendo, y dos meses, por lo que 9 hombres sern

necesarios. Aadir 6 hombres asignados a los 3.

Figura 2,6

Figura 2.7

3. Reprogramar. Me gusta el consejo dado por P. Fagg, un

experimentado ingeniero de hardware, "Take no pequea desliza." Es

decir, permitir el tiempo suficiente en el nuevo calendario para

asegurar que el trabajo puede ser realizado cuidadosamente ya

fondo, y que la reprogramacin no tendr que hacer de nuevo.4. Recortar la tarea. En la prctica, esto tiende a suceder de todos

modos, una vez que el equipo de calendario seala el deslizamiento.

En caso de que la demora de los costes secundarios son muy altos,

esta es la nica accin viable.

El gerente de la nica alternativa para recortar oficialmente y

cuidadosamente, a reprogramar, o para ver la tarea silenciosa

obtener recortado por precipitada e incompleta de diseo de

pruebas.

En los dos primeros casos, insistiendo en que la tarea se complet sin

modificaciones en cuatro meses es desastroso. Considerar laregeneracin efectos, por ejemplo, para la primera alternativa (Fig.

2.8). Los dos nuevos hombres, sin embargo competente y sin

embargo

rpidamente contratados, requerir la capacitacin en la tarea de uno

de los hombres experimentados. Si esto toma un mes, 3 meses-

hombre que se ha dedicado a trabajar no en la estimacin original.

Adems, la tarea, inicialmente dividido de tres maneras, debe ser

repartitioned en cinco partes, por lo que algunos trabajos ya

realizados se perdern, y pruebas del sistema deben ser alargado. As

que al final del tercer mes, sustancialmente ms de 7 meses-hombreesfuerzo de seguir siendo, y 5 personas capacitadas y se dispone de


7/17

un mes. En la fig. 2.8 sugiere, el producto es tan tarde como si nadie

se haba aadido (Fig. 2.6).

La esperanza de que hacer en cuatro meses, teniendo en cuenta slo

el tiempo de formacin y no reparticionado y sistemas de ensayo

adicionales, requerir la adicin de 4 hombres, no 2, al final del

segundo mes. Para cubrir reparticionado sistema de prueba y efectos,habra que aadir todava otros hombres. Ahora, sin embargo, uno

tiene al menos un equipo de 7-hombre, no un 3-un hombre y, por

consiguiente, de aspectos tales como el equipo de organizacin y

divisin de tareas son diferentes en especie, no slo en grado.

Observe que al final del tercer mes las cosas parecen muy negro. El

1ro de marzo hito no se ha alcanzado a pesar de todos

Figura 2.8

el esfuerzo de gestin. La tentacin es muy fuerte para repetir elciclo, un nmero an mayor de la mano de obra. Ah est la locura. Lo

anterior supone que slo el primer hito fue misestimated.

Si en marzo me la hace una hiptesis conservadora de que todo el

programa era optimista, como la fig. 2.7 muestra, se quiere aadir a

slo 6 hombres en la tarea original. Clculo de la formacin,

reparticionado, sistema de pruebas de los efectos se deja como

ejercicio para el lector. Sin duda, el desastre regenerativa producir

un producto ms pobres, ms tarde, que se

reprogramacin con el original de tres hombres, unaugmented.

Demasiado escandaloso, que el estado de la Ley de Brooks:Adicin de la mano de obra a otro proyecto de software hace que sea

ms tarde.

Esta es, entonces, la desmitificacin del hombre-mes. El nmero de

meses de un proyecto depende de sus limitaciones secuencial. El

nmero mximo de los hombres depende del nmero de subtareas

independientes. A partir de estas dos cantidades se puede obtener

horarios con menos hombres y ms meses. (El nico riesgo es

producto de la obsolescencia.) Uno no puede, sin embargo, obtener

horarios viables mediante un mayor nmero de hombres y un menor

nmero de meses. Ms proyectos de software han ido mal por faltade tiempo del calendario que para todas las otras causas

combinadas.


8/17

TheMythicalMan-MonthGood cooking fakes time. Ifyou are made to wait, it is to serve you

better, and to please you.

14 TheMythicalMan-MonthMoresoftwareprojectshavegoneawryforlackofcalendartime than for

allothercausescombined.Whyisthiscauseofdisaster socommon?

First, our techniques of estimating are poorly developed. More seriously,

theyreflectanunvoicedassumptionwhichisquiteun- true, i.e., that all

willgowell.

Second, our estimating techniques fallaciously confuse effort with

progress, hiding the assumption that men and months are

interchangeable.

Third, because we are uncertain ofour estimates, software managers

oftenlackthecourteousstubbornnessofAntoine'schef.

Fourth, schedule progress is poorly monitored.Techniques provenand

routine inotherengineeringdisciplinesareconsidered radical innovations

insoftwareengineering.

Fifth, when schedule slippage is recognized, thenatural (and traditional)

response is to add manpower. Like dousing a fire with gasoline, this

makes matters worse, much worse. More fire re- quiresmoregasoline,

andthusbeginsaregenerativecyclewhich ends in disaster.

Schedule monitoring will be the subject of a separate essay. Let us

considerotheraspectsoftheproblem inmoredetail.

Optimism

All programmers are optimists. Perhaps this modern sorcery espe- cially

attracts those who believe in happy endings and fairy god- mothers.

Perhapsthehundredsofnittyfrustrationsdriveawayall but those who

habitually focus on the end goal. Perhaps it is merelythatcomputers

areyoung,programmersareyounger,and theyoungarealwaysoptimists.

Buthowevertheselectionprocess works, the result is indisputable: "This

timeitwillsurelyrun,"or

"Ijustfound the lastbug."

So the first false assumption that underlies the scheduling of systems

programmingisthatallwillgowell, i.e., thateach taskwill hikeonly as long

as it "ought"to take.


9/17

Regenerative Schedule Disaster 9

The pervasiveness of optimism among programmers deserves more

thanaflipanalysis. DorothySayers, inherexcellentbook, TheMindof

the Maker, divides creative activity into three stages: the idea, the

implementation, and the interaction. A book, then, oracomputer,or

a program comes into existence first as an ideal construct, built

outsidetimeandspace,butcompleteinthemind of the author. It isrealized in time and space, by pen, ink, and paper, or by wire,

silicon, and ferrite.The creation is complete when someone reads

the book, uses the computer, or runs the program, thereby

interactingwiththemind ofthemaker.

This description, which Miss Sayers uses to illuminate not onlyhuman

creativeactivitybutalsotheChristiandoctrineofthe Trinity,willhelpusin

ourpresenttask.Forthehumanmakersof things, the incompletenesses

and inconsistencies of our ideas become clear only during

implementation.Thus it is that writing, experimentation, "working out"

areessentialdisciplinesforthe theoretician.

Inmanycreativeactivitiesthemediumofexecutionisintractable. Lumber

splits; paints smear; electrical circuits ring.These physical limitations of

themedium constrain the ideas that may be expressed, and they also

create unexpected difficulties in the implementation.

Implementation,then,takes timeand sweatbothbecauseof thephysical

mediaandbecauseofthe inadequaciesoftheunder- lyingideas.Wetend

to blame the physical media for most of our implementation difficulties;

for the media are not "ours" in the way the ideas are, andourpride

colorsourjudgment.

Computer programming, however, creates with an exceed-

ingly tractable medium. The programmer builds from pure

thought-stuff:conceptsandveryflexiblerepresentationsthereof. Because

the medium is tractable, we expect few difficulties in implementation;

hence our pervasive optimism. Because our ideas are faulty, we have

bugs;henceouroptimismisunjustified.

In a single task, the assumption that all will go well has a

probabilisticeffectontheschedule. Itmight indeedgoas for there is aprobability distribution for the delay that will be encountered,and"no

delay" has a finite probability. A large programming effort, however,

consists of many tasks, some chained end-to-end.The probability that

eachwillgowellbecomesvanishingly small.

The'Man-Month

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 numberofmonths. Progress does not.Hence the man-month as a unit for measuring


10/17

the size ofajob is a dangerous and deceptive myth. It implies that men

and months are interchangeable.

Menandmonthsareinterchangeablecommoditiesonlywhen

a taskcanbepartitionedamongmanyworkerswithnocommunicationamongthem(Fig.2.1).Thisistrueofreapingwheatorpicking cotton;itis

notevenapproximatelytrueofsystemsprogramming.

Men

Fig. 2.1 Time versus number of workersperfectly partitionabletask

TheMan-Month 17

When a task cannot be partitioned because of sequential constraints,

theapplicationofmoreefforthasnoeffectonthesched- ule (Fig.2.2).

Thebearingofachild takesninemonths,nomatter how many women

are assigned. Many software tasks have this characteristic because of

thesequentialnatureofdebugging.


11/17


Fig. 2.2 Time versus number of workersunpartitionable task

Intasksthatcanbepartitionedbutwhichrequirecommunication 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

somewhatpoorerthananeventradeofmenfor months(Fig.2.3).

Men

Fig. 2.3 Time versus number of workerspartitionable task requiring

communication

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 partitioned, so this part of the added effort varies linearly

with the number of workers.1

Intercommunication is worse. If each part of the task must be separately

coordinated with each other part/ the effort increases as n(n-I)/2. Threeworkers require three times as much pairwise intercommunication as

two; four require six times as much as two. If, moreover, there need to be

conferences among three, four, etc., workers to resolve things jointly,

matters get worse yet. The added effort of communicating may fully

counteract the division of the original task and bring us to the situation

of Fig. 2.4.


12/17

Men

Fig.2.4 TimeversusnumberofworkerstaskwithcomplexinterrelationshipsSincesoftwareconstructionisinherentlyasystemseffortan exercisein

complex interrelationshipscommunication effort is great,anditquicklydominates the decrease in individual task time brought about by

partitioning. Adding more men then lengthens, not shortens, the

schedule.

SystemsTestNo parts of the schedule are so thoroughly affected by sequential

constraints as component debugging and system test. Further- more,

the time required depends on the number and subtlety of the errors

encountered. Theoretically this number should be zero. Because ofoptimism,weusuallyexpect thenumberofbugs tobesmaller than it

turns out to be. Therefore testing is usually the most misscheduled

partofprogramming.

For some years I have been successfully using the following rule of

thumb for scheduling a software task:

l/3planning

l/6coding

l/4componenttestandearlysystemtest

l/4systemtest,allcomponentsinhand.

Thisdiffersfromconventionalschedulinginseveralimportant ways:

1. Thefractiondevotedtoplanningislargerthannormal.Even so, it is

barely enough to produce a detailed and solid specification, and not

enoughtoincluderesearchorexplorationoftotallynewtechniques.


13/17


2. The halfofthescheduledevotedtodebuggingofcompleted code is

muchlargerthannormal.

3. The part that is easy to estimate, i.e., coding, is given only one-

sixth ofthe schedule.

In examining conventionally scheduled projects, I have found that few

allowed one-half of the projected schedule for testing, but that most

did indeedspendhalfofthe actual scheduleforthat purpose. Many of

these were on schedule until and except in system testing.2

Failure to allowenough time for system test, in particular, is peculiarly

disastrous. Since the delay comes at the end of the schedule, no

one is aware of schedule trouble until almost the deliverydate.Bad

news,lateandwithoutwarning,isunsettling

tocustomers andtomanagers.

Furthermore,delayatthispointhasunusuallyseverefinan- cial,as well

as psychological, repercussions. The project is fully staffed, and cost-

per-day ismaximum. Moreseriously, thesoft- ware is to support other

business effort (shipping of computers, operationofnew facilities,etc.)

andthesecondarycostsofdelay- ingtheseareveryhigh,foritisalmost

timeforsoftwareshipment.

Indeed, these secondary costs may far outweigh all others. It is

thereforevery importanttoallowenoughsystemtesttimeinthe original

schedule.

Gutless EstimatingObserve that for the programmer, as for the chef, the urgency of the

patronmaygovernthescheduledcompletionofthetask,but

it cannot govern the actual completion. An omelette, promised in two

minutes,mayappeartobeprogressingnicely.Butwhen ithas notsetin

twominutes,thecustomerhastwochoiceswaitoreat

itraw. Softwarecustomershavehadthesamechoices.

The cook has another choice; he can turn up theheat.The resultis

oftenanomelettenothingcansaveburnedinonepart, raw in another.

Now I do not think software managers have less inherent

courageandfirmnessthanchefs,northanotherengineeringman- agers.

But false scheduling to match the patron's desired date is much more

common in our discipline than elsewhere in engineer- ing. It is very

difficult to make a vigorous, plausible, andjob- risking defense ofan


14/17

estimate that is derivedbynoquantitative method, supported by little

data, and certified chiefly by the hunches of the managers.

Clearly two solutions are needed. We need to develop and publicize

productivity figures, bug-incidence figures, estimating rules,andsoon.

Thewholeprofessioncanonlyprofitfromsharing suchdata.

Until estimating ison a sounder basis, individual managers

will need to stiffen their backbones and defend their estimates with

the assurance that their poor hunches are better than wish- derived

estimates.

Regenerative Schedule DisasterWhat does one do when an essential software project is behind

schedule?Addmanpower,naturally.AsFigs.2.1through2.4suggest, this

mayormaynothelp.

Let us consider an example.3

Suppose a task is estimated at 12 man-

monthsandassigned to threemen for fourmonths,and that there are

measurablemilepostsA,B,C,D,whicharescheduled to fall at the end

of each month (Fig. 2.5).

Now suppose the first milepost is not reached until two months

haveelapsed(Fig. 2.6).Whatarethealternativesfacing themanager?

1. Assumethatthetaskmustbedoneontime.Assumethatonly thefirst

partofthetaskwasmisestimated,soFig.2.6tellsthe story accurately.Then9man-months ofeffortremain,and twomonths,so4Vmenwill

beneeded.Add2mentothe3 assigned.

2. Assume thatthetaskmustbedoneontime.Assumethatthe whole

estimate was uniformly low, so that Fig. 2.7 really describes the

situation.Then18man-monthsofeffort remain, and two months, so 9

menwillbeneeded.Add6mentothe

3assigned.


15/17


Figure 2,6

Figure 2.7

3. Reschedule. I like the advice given by P. Fagg, an experienced

hardware engineer, "Take no small slips."That is, allow enoughtime

in the new schedule to ensure that the work can be carefully andthoroughlydone,andthatreschedulingwill nothave tobedoneagain.

4.Trimthetask.Inpracticethistendstohappenanyway,once the team

observes schedule slippage. Where the secondary costs of delay are

very high, this is the only feasible action. The manager's only

alternatives are to trim it formally and carefully, to reschedule, or to

watch the task get silently trimmed by hasty design and incomplete

testing.

In the first two cases, insisting that the unaltered task be completed

in four months is disastrous. Consider the regenerative effects, for

example, for the first alternative (Fig. 2.8).The two new men, however


16/17

competent and however quickly recruited, will require training in the

taskby one of the experienced men. If this takesamonth, 3man-months

willhavebeendevotedtoworknotin the originalestimate.Furthermore,the

task,originallypartitionedthree ways, must be repartitioned into five

parts; hence some work already done will be lost, and system testing

mustbelengthened. Soattheendofthethirdmonth,substantiallymorethan 7 man- months of effort remain, and 5 trained people and one

monthare available.AsFig.2.8suggests,theproduct isjustas lateas if

no onehadbeenadded(Fig. 2.6).

Tohopetogetdoneinfourmonths,consideringonlytraining timeandnot

repartitioningand extra systems test, would require adding 4 men, not

2, at the end of the second month. To cover repartitioningandsystem

testeffects,onewouldhave to add still other men. Now, however, one

hasat leasta7-manteam,nota

3-manone; thussuchaspectsasteamorganizationandtaskdivision are

different inkind,notmerelyindegree.

Notice that by the end ofthe third month things look very black.The

March1milestonehasnotbeenreachedinspiteofall


17/17


Figure 2.8themanagerialeffort.The temptation isverystrong to repeat the cycle,

adding yet more manpower. Therein lies madness. The foregoing

assumedthatonlythefirstmilestonewas misestimated. IfonMarch Ione

makes the conservative assumption that the whole schedule was

optimistic,asFig.2.7depicts,one wantstoadd6menjust tothe original

task. Calculation of the training, repartitioning,system testingeffects is

leftasanexercise forthe reader. Without a doubt, the regenerative

disaster will yield a poorer product, later, than would rescheduling

with the original threemen, unaugmented.

Oversimplifying outrageously,westateBrooks'sLaw:

Adding manpower to a latesoftwareproject makes it later.

Thisthen is the demythologizing of the man-month. The numberof

months of a project depends upon its sequential constraints. The

maximumnumberofmendependsuponthenumber

of independent subtasks. From these two quantities one can derive

schedulesusingfewermenandmoremonths. (Theonlyrisk is product

obsolescence.)Onecannot,however,getworkableschedulesusingmore

menandfewermonths.Moresoftwareprojects havegoneawryforlack

ofcalendartimethanforallothercauses combined.

Documents

Mito Hombre Mes