Мифический человеко-месяц или как создаются программные системы

Есть масса примеров, подсказанных другими искусствами и ремеслами, которые подводят к мнению, что дисциплина идет на пользу. Действительно, афоризм художника гласит, что «форма освобождает». Самые ужасны строения — это те, бюджет которых был слишком велик для поставленных целей. Творческую активность Баха едва ли могла подавлять необходимость еженедельная необходимость изготавливать кантату определенного вида. Я уверен, что архитектура компьютера Stretch стала бы лучше, если бы на нее наложили более жесткие ограничения; так, ограничения, наложенные бюджетом на System/360 Model 30, по моему мнению, принесли лишь пользу архитектуре Model 75.

Аналогично, я считаю, что получение архитектуры извне усиливает, а не подавляет творческую активность группы исполнителей. Они сразу сосредоточиваются на той части задачи, которой никто не занимался, и в результате изобретательность бьет ключом. В не ограничиваемой группе большая часть обдумывания и обсуждения посвящена архитектурным решениям в ущерб реализации.[5]

Этот многократно наблюдавшийся мной эффект подтвердил Р. У. Конвей (R. W. Conway), чья группа разработала в Корнельском университете компилятор PL/C для языка PL/I. Он говорит: «В конечном итоге мы решили реализовать язык без изменений и усовершенствований, поскольку обсуждение языка отняло бы у нас все силы.»[6]

Чем заняться разработчику, пока он вынужден ждать?

Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.

У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это должным образом. Это должно было занять 10 месяцев — на три больше, чем отводилось по графику.

У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десяти месяцев будут бить баклуши.

На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже. Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорогостоящими, и, по моим оценкам, отладка удлинилась на год.

Конечно, многие факторы повлияли на принятие этого ошибочного решения, но определяющими были желание уложиться в график и стремление занять работой этих 150 человек. Пение этих сирен таит смертельные опасности, которые я и хочу сейчас показать.

Когда предлагается, чтобы все внешние спецификации для компьютерной или программной системы были составлены небольшой командой архитекторов, исполнители выдвигают три возражения:

• Спецификации будут перегружены функциями и не будут учитывать практических затрат на реализацию.

• Архитекторы получат все радости творчества и заблокируют изобретательность исполнителей.

• Многочисленным исполнителям придется ожидать в праздности, пока спецификации пройдут через узкое горлышко команды архитекторов.

Первое возражение отражает реальную опасность и будет рассмотрено в следующей главе. Остальные два являются чистым заблуждением. Как мы видели выше, разработка также является в высшей степени творческой деятельностью. Возможность проявить творчество и изобретательность при разработке незначительно ограничивается необходимостью работать в рамках заданных внешних спецификаций, и такая дисциплина может даже усилить степень творчества. Это, несомненно, верно для проекта в целом.

Последнее возражение касается планирования временных рамок и этапов. Проще всего воздержаться от найма исполнителей до завершения работы над спецификациями. Когда воздвигается здание, так и поступают.

Однако при создании компьютерных систем темпы выше, и желательно уплотнить график работ. В какой мере разработка спецификаций и разработка могут перекрываться?

Как отмечает Блау, всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Оказывается, что на практике их можно начинать параллельно и продолжать одновременно.