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
7/30/2019 Mito Hombre Mes
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
7/30/2019 Mito Hombre Mes
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
7/30/2019 Mito Hombre Mes
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
7/30/2019 Mito Hombre Mes
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
7/30/2019 Mito Hombre Mes
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/30/2019 Mito Hombre Mes
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.
7/30/2019 Mito Hombre Mes
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.
7/30/2019 Mito Hombre Mes
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 pro- gramming 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
7/30/2019 Mito Hombre Mes
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 con- straints,
theapplicationofmoreefforthasnoeffectonthesched- ule (Fig.2.2).
Thebearingofachild takesninemonths,nomatter how many women
are assigned. Many software tasks have this characteristic because of
thesequentialnatureofdebugging.
7/30/2019 Mito Hombre Mes
11/17
Regenerative Schedule Disaster 11
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.
7/30/2019 Mito Hombre Mes
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.
7/30/2019 Mito Hombre Mes
13/17
Regenerative Schedule Disaster 13
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
7/30/2019 Mito Hombre Mes
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.
7/30/2019 Mito Hombre Mes
15/17
Regenerative Schedule Disaster 15
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
7/30/2019 Mito Hombre Mes
16/17
competent and however quickly recruited, will re- quire 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
7/30/2019 Mito Hombre Mes
17/17
Regenerative Schedule Disaster 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.
Top Related