[{{mminutes}}:{{sseconds}}] X
Пользователь приглашает вас присоединиться к открытой игре игре с друзьями .
The Mythical Man-Month
(2)       Используют 14 человек

Комментарии

Ни одного комментария.
Написать тут
Описание:
The Mythical Man-Month
Автор:
diunko
Создан:
21 января 2011 в 02:45 (текущая версия от 30 января 2011 в 12:09)
Публичный:
Да
Тип словаря:
Книга
Последовательные отрывки из загруженного файла.
Содержание:
789 отрывков, 379358 символов
1 The Tar Pit
No scene from prehistory is quite so vivid as that of the mortal
struggles of great beasts in the tar pits. In the mind's eye one sees
dinosaurs, mammoths, and sabertoothed tigers struggling against
the grip of the tar. The fiercer the struggle, the more entangling the
tar, and no beast is so strong or so skillful but that he ultimately
sinks.
Large-system programming has over the past decade been
such a tar pit, and many great and powerful beasts have thrashed
violently in it.
2 Most have emerged with running systemsв"few
have met goals, schedules, and budgets. Large and small, massive
or wiry, team after team has become entangled in the tar. No one
thing seems to cause the difficultyв"any particular paw can be
pulled away. But the accumulation of simultaneous and interacting
factors brings slower and slower motion. Everyone seems to
have been surprised by the stickiness of the problem, and it is hard
to discern the nature of it.
3 But we must try to understand it if we
are to solve it.
Therefore let us begin by identifying the craft of system programming
and the joys and woes inherent in it.
The Programming Systems Product
One occasionally reads newspaper accounts of how two programmers
in a remodeled garage have built an important program that
surpasses the best efforts of large teams. And every programmer
is prepared to believe such tales, for he knows that he could build
any program much faster than the 1000 statementsyear reported
for industrial teams.
4 Why then have not all industrial programming teams been
replaced by dedicated garage duos? One must look at what is being
produced.
In the upper left of Fig. 1.1 is a program. It is complete in itself,
ready to be run by the author on the system on which it was
developed. That is the thing commonly produced in garages, and
that is the object the individual programmer uses in estimating
productivity.
5 There are two ways a program can be converted into a more
useful, but more costly, object. These two ways are represented by
the boundaries in the diagram.
Moving down across the horizontal boundary, a program
becomes a programming product. This is a program that can be run,
tested, repaired, and extended by anybody. It is usable in many
operating environments, for many sets of data. To become a generally
usable programming product, a program must be written in a
generalized fashion.
6 In particular the range and form of inputs
must be generalized as much as the basic algorithm will reasonably
allow. Then the program must be thoroughly tested, so that it can
be depended upon. This means that a substantial bank of test
cases, exploring the input range and probing its boundaries, must
be prepared, run, and recorded. Finally, promotion of a program
to a programming product requires its thorough documentation, so
that anyone may use it, fix it, and extend it.
7 As a rule of thumb,
I estimate that a programming product costs at least three times as
much as a debugged program with the same function.
Moving across the vertical boundary, a program becomes a
component in a programming system. This is a collection ofinteracting
programs, coordinated in function and disciplined in format,
so that the assemblage constitutes an entire facility for large tasks.
To become a programming system component, a program must be
written so that every input and output conforms in syntax and
semantics with precisely defined interfaces.
8 The program must
also be designed so that it uses only a prescribed budget of re-
sourcesв"memory space, input-output devices, computer time. Finally,
the program must be tested with other system components,
in all expected combinations. This testing must be extensive, for
the number of cases grows combinatorially. It is time-consuming,
for subtle bugs arise from unexpected interactions of debugged
components.
9 A programming system component costs at least
three times as much as a stand-alone program of the same function.
The cost may be greater if the system has many components.
In the lower right-hand corner of Fig. 1.1 stands the programming
systems product. This differs from the simple program in all of
the above ways. It costs nine times as much. But it is the truly
useful object, the intended product of most system programming
efforts.
10 The Joys of the Craft
Why is programming fun? What delights may its practitioner
expect as his reward?
First is the sheer joy of making things. As the child delights
in his mud pie, so the adult enjoys building things, especially
things of his own design. I think this delight must be an image of
God's delight in making things, a delight shown in the distinctness
and newness of each leaf and each snowflake.
 

Связаться
Выделить
Выделите фрагменты страницы, относящиеся к вашему сообщению
Скрыть сведения
Скрыть всю личную информацию
Отмена