Мифический человеко-месяц

      "Если программистский проект не укладывается в сроки, то добавление рабочей силы только задержит его окончание".
      Таким образом, мы развеиваем миф о человеко-месяце. Число месяцев, отводимых на проект, зависит от ограничений на его линейность. Максимальное число людей зависит от числа независимых подзадач. Исходя из г"тпх двух величрга, можно построить график, рассчитанный на меньшее число людей и большее количество месяцев. (Единственная опасность заключается в том, что конечный продукт устареет.) Нельзя, однако, составить работоспособный график, используя больше людей и меньше месяцев. В большинстве программистских проектов дела шли скверно скорее всего из-за нехватки календарного времени, нежели по всем другим причинам, вместе взятым.
      III. ХИРУРГИЧЕСКАЯ БРИГАДА
      "Эти исследования обнаружили большие различия в пределах индивидуальной производительности - иногда даже на целый порядок".
      (Сакмен, Эриксони Грант)
      На конференциях по программированию непрерывно раздаются голоса молодых руководителей, утверждающих, что они предпочитают иметь дело с небольшой боевой группой первоклассных специалистов, нежели вести проект, в котором заняты сотни программистов среднего уровня. Так хотелось бы и всем нам.
      Однако эта наивная формулировка альтернативы уводит от ответа на тяжелый вопрос - как построить большую систему в разумный срок? Рассмотрим каждую сторону этого вопроса более подробно.
      В чем проблема?
      Руководители программистских проектов давно уже поняли, как значительны различия в производительности хороших и плохих программистов. Тем не менее результаты точных измерений этой величины просто поражают. В одной из своих работ Сакмен, Эриксон и Грант измеряли производительность группы опытных программистов. Даже внутри этой группы отношение максимальной и минимальной производительности в среднем составило 10:1, а для времени работы программы и затрат памяти - 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10 раз больше, чем у того, кто зарабатывает 10 тыс. долларов. Обратное также может быть справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.)
      Выше я уже доказал, что увеличение числа людей, занятых в проекте, повышает его стоимость, ибо основные затраты приходятся на обеспечение связи и на устранение последствий плохой организации этой связи (комплексная отладка). Это и приводит к Стремлению руководителей максимально ограничить число людей, работающих над системой.
      Действительно, опыт создания почти всех больших систем программирования показал, что политика грубой силы дорого обходится, работа оказывается медленной и малоэффективной и приводит к системам, в которых отсутствует концептуальное единство:
      OS/360, Exes-8, Scope-6600, Multics, TSS, SAGE - этот список можно существенно расширить.
      Напрашивается вывод: если в проекте занято 200 человек и среди них - 25 руководителей, т. е. наиболее компетентных и опытных программистов, то следует уволить 175 исполнителей и заставить руководителей вернуться к программированию.
      Давайте, однако, проверим это решение. С одной стороны, оно все же не соответствует идеальному представлению о небольшой боевой группе, которая, по общему мнению, не должна превышать 10 человек. Она слишком велика, так что потребует по меньшей мере двух уровней руководства, или около пяти руководителей. А это вызовет дополнительные потребности в финансах, сотрудниках, рабочих местах, секретарях и операторах ЭВМ.
      С другой стороны, первоначальная группа в 200 человек не настолько велика, чтобы можно было сделать действительно большую систему методом грубой силы. Рассмотрим, например, операционную систему OS/360. В пиковые периоды над ней работало около 1000 человек - программисты, составители технической документации, операторы, лаборанты, секретари, руководители, вспомогательные службы и т. д. За период с 1963 по 1966 гг. около 5000 человеко-лет понадобилось на проектирование, реализацию этой системы и создание документации на нее. Нашей группе из 200 человек понадобилось бы 25 лет, чтобы довести систему до ее нынешнего состояния, да и то при условии, что люди и месяцы действительно взаимозаменяемы.
      Вот тут-то и обнаруживается слабая сторона концепции маленькой энергичной группы: это слишком медленно для действительно больших систем. Посмотрим, что получилось бы, если бы создание операционной системы OS/360 поручили такой группе. Допустим, в ней 10 человек. Пусть благодаря энергии и опыту их производительность в программировании и создании документации в 7 раз выше, чем у средних программистов. Допустим, что OS/360 создавалась только средними программистами (но это, впрочем, очень далеко от истины). И допустим, наконец, что еще один коэффициент повышения производительности, равный 7, появился из-за уменьшения затрат на обеспечение взаимосвязи в меньшем коллективе. Допустим, также, что состав группы не менялся все это время. Тогда 5000/(10>Предложение Миллза
      Харлан Миллз выдвинул оригинальное и творческое решение этой проблемы2'3). Он предлагает, чтобы над каждой частью большой задачи работала отдельная группа, и считает, что группа должна быть организована по принципу хирургической бригады, где операцию делает один, а остальные ему ассистируют.
      По некотором размышлении видно, что идея, если удастся ее осуществить, будет вполне соответствовать нашим желаниям. Две - три головы заняты проектированием и разработкой, для реализации же их идей имеется необходимое множество рук. Но сможет ли работать такая бригада? Кто будет в ней анестезиологом, медицинской сестрой, и как распределить работу? Позвольте мне, свободно обращаясь с метафорами, предложить возможный вариант такой огранизации.
      Хирург. Миллз называет его главным программистом. Он сам, лично, определяет функциональные си'-'-цификации и показатели производительности, разрабатывает программу, пишет, отлаживает ее и готовит документацию. Он пользуется структурированным языком программирования типа PL/I и имеет диалоговый доступ к вычислительной системе, которая не только пропускает его тесты, но и хранит различные версии его программы, позволяет легко модифицировать файлы и обеспечивает редактирование текстов для его документации. Он должен обладать замечательным талантом, десятилетним опытом работы н значительными системными и прикладными навыками.
      Второй пилот. Он - правая рука хирурга, его второе "я", и способен выполнить любую часть работы, но не столь опытен. Он принимает участие в разрабог-ке, обсуждении и оценке проекта вместе с хирургом, который проверяет на нем свои идеи, но не обязательно следует его советам. Второй пилот представляет свою бригаду на дискуссиях, взаимодействует с другими бригадами. Он до тонкостей знает всю программу. Он ищет альтернативные стратегии проектирования. Очевидно, что второй пилот страхует дело от несчастья с хирургом. Он может даже программировать, но не отвечает ни за одну часть машинной программы.
      Администратор. Хирург является начальником, п за ним остается последнее слово по вопросам персонала, оплаты, помещений и т. д. Но он должен посвящать всему этому как можно меньше времени. Поэтому нужен профессиональный администратор, который бы занимался деньгами, людьми, машинами, а также входил в контакты с администрацией всей организации.
      Бейкер считает, что администратор будет занят весь рабочий день, только если взаимоотношения пользователя с разработчиком предъявляют значительные \ правовые, отчетные или финансовые требования к проекту. В противном случае один администратор может обслуживать две бригады.
      Редактор. Хирург отвечает за создание документации - для максимальной ясности он должен сам ее написать. Причем это справедливо и для внешних, и для внутренних описаний. Редактор же получает рукопись хирурга и критикует ее, перерабатывает, снабжает ссылками и библиографией, возится с различными версиями и наблюдает за ее размножением и распространением.
      Два секретаря. И администратору, и редактору нужны свои секретари; секретарь администратора будет вести корреспонденцию проекта и архивы.
      Архивариус. Он отвечает за ведение всей технической документации в бригаде. Архивариус знаком с обязанностями секретаря и в его ведении информация, хранящаяся как в машине, так и на столах программистов.
      Выход на машину осуществляется через архивариуса, выдачи также попадают к нему. Самые последние распечатки хранятся в рабочем журнале; все предыдущие - в архиве, в хронологическом порядке.
      В концепциях Миллза жизненно необходимым является превращение программирования "из индивидуального в общественное дело", для чего нужно сделать все результаты выходов на машину открытыми для всех членов бригады п осознать, что программы п данные являются собственностью бригады, а не частной собственностью.
      В функции архивариуса входит освобождение программистов от канцелярской поденщины, причем он должен выполнять эти обычно столь неприятные обязанности систематически и с высокой производительностью, тем самым способствуя появлению наиболее ценного результата работы бригады - рабочего продукта. Очевидно, что вышеописанная схема предполагает работу в пакетном режиме. Когда используются диалоговые терминалы, в частности, те, что позволяют работать без распечаток, обязанности, архивариуса не исчезают они изменяются. Теперь он вносит в общие копии программ все изменения с отдельных рабочих копий, по-прежнему выходит на машину с пакетом программ и использует свой собственный диалоговый терминал для контроля за полнотой и доступностью растущего продукта.
      Инструментальщик. Редактирование файлов, редактирование текстов и служба диалоговой отладки теперь имеются почти всюду, так что нет никакой необходимости каждой бригаде иметь свою собственную машину и группу ее обслуживания, но тем не менее нужен свой инструментарий, набор вспомогательных средств, преимущественно диалоговых. Их приобретение, эксплуатация и усовершенствованно составят круг обязанностей опытного системного программиста - инструментальщика. Каждой бригаде понадобится такой инструментальщик, независимо от качества и надежности централизованного обслуживания. В своей работе он должен руководствоваться нуждами пли желаниями хирурга; требования других бригад его не касаются. В обязанности разработчика инструментария входит создание специализированных служебных программ, каталогизированных процедур, библиотек макрокоманд и т. д.
      Контролер. Хирургу необходимо иметь набор подходящих тестов для отладки частей своей программы по мере ее написания и для отладки программы как единого целого. Контролер, таким образом, одновременно и враг, изобретающий системные тесты, руководствуясь функциональными спецификациями, и друг, предлагающий тестовые данные для повседневной оч-ладки. Он должен также планировать последовательность тестов и подготавливать оснастку для комплексной отладки.
      Языковед. Со времени появления языка алгол-60 выяснилось, что при работе с большинством вычислительных систем нужны один-два профессионала, посвященных во все тонкости языка программирования. Эти специалисты оказались очень полезными, к ним постоянно обращались за консультациями. Они должны обладать совершенно другими талантами, чем хирург, который по самой своей сути является разработчиком систем. Хирург мыслит образами, языковед же может найти красивый и эффективный способ использования языка в трудных, темных или запутанных ситуациях. Зачастую ему придется посвятить два-три дня небольшим исследованиям в поисках хорошего метода. Один языковед может обслуживать двоих или троих хирургов.
      Итак, мы предложили способ организации группы программистов, состоящей из 10 человек, и распределение ролей внутри этой группы, используя в качестве модели хирургическую бригаду.
      Как она работает? Многие идеи предложенного выше принципа организации коллектива соответствуют нашим требованиям. Десять человек, из них семь профессионалов, работают над проблемой, но система является продуктом одного человека, в крайнем случае - двоих, выступающих как одно целое.
      Отметим, в частности, различия между обычным коллективом программистов из двух человек и группой "хирург - второй пилот". Во-первых, в обычных коллектпвах вся работа разделена между сотрудниками, и каждый из них отвечает за разработку и реализацию своей части. В хирургической бригаде и хирург, и BW рой пилот в курсе всего проекта и всей программы. Это снимает проблему дележа памяти, обращений R дискам и т. п. И, кроме того, сохраняется концептуальное единство работы. Во-вторых, в обычных коллективах все сотрудники равны, и неизбежные различия в оценках требуют постоянных обсуждений и компромиссов. Поскольку работа и ресурсы разделены, различия в суждениях, конечно, подчинены общей стратегии и правилам взаимодействия, но они усугубляются противоположностями интересов,- например, чья часть памяти будет использоваться для буфера. В хирургической бригаде нет различий в интересах, а противоречия в мнениях разрешаются самим хирургом единолично. Эти два обстоятельства - единство задачи п связь только по принципу подчинения - позволяют хирургической бригаде действовать как одно целое.
      Рис. 3.1. Структура связей в коллективе программистов из 10 человек.
      Таким образом, строгое распределение функции между сотрудниками бригады является ключом к повышению ее производительности, поскольку оно, обеспечивает гораздо более простую структуру связей между сотрудниками, как это видно на рис. 3.1.
      В статье Бейкера3) рассказывается о проверке принципа хирургической бригады в процессе выполнения одного небольшого проекта. Бригада работала так, как и предполагалось в этом случае, и с очень хорошими результатами.
      "Экскалация". Пока все хорошо. Проблема, однако, заключается в том, что же делать с проектами, создание которых требует не 20 или 30, а 5000 человеко-лет. Группа из 10 сотрудников может работать эффективно и независимо от того, как она организована, если только вся задача находится в сфере ее действия. Но как использовать концепцию хирургической бригады применительно к большой задаче, в решении которой принимают участие несколько сот человек?
      Залог успеха "эскалации" заключается в том, что нами уже обеспечена высокая степень концептуального единства на уровне частей - в каждой из них число умов, определяющих проект, сократилось в семь раз. Тогда можно отдать всю работу 200 сотрудникам, но проблемы координации поручить 20 хирургам.
      Для проблемы координации, однако, надо использовать специальные методы, которые подробно обсуждаются в следующих разделах. Пока же достаточно сказать, что вся система тоже должна обладать концептуальным единством, а ее разработкой должен заниматься системный архитектор. Чтобы обеспечить руководство проектом, необходимо провести четкое различие между архитектурой и реализацией, и системный архитектор должен посвятить себя исключительно архитектуре. Такое распределение ролей и такая методика полностью оправдали себя и оказались очень эффективными.
      IV. АРИСТОКРАТИЯ, ДЕМОКРАТИЯ И СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ
      "Этот великолепный храм - несравненное произведение искусства. В догмах, которые он утверждает, нет ни черствости, ни беспорядка. Это зенит стиля, работа художников, которые осознали и творчески переработали опыт своих предшественников, полностью овладели методами своего времени, но использовали их, нигде не проявляя никакой чрезмерности. Несомненно, что именно Жан Э'0рбе разработал общий план, которого придерживались, по крайней мере в важнейших чертах, его последователи. В этом заключается, одна из причин полной гармонии всего сооружения".
      (Путеводитель по Рейнскому Собору)
      Концептуальное единство
      Отдельные части всех европейских соборов различаются по своему стилю, потому что они создавались разными поколениями строителей. Каждое новое поколение пыталось "улучшить" старый проект в соответствии с изменениями моды или же различиями индивидуальных вкусов. Спокойный норманский трансепт примыкает к парящему готическому нефу и одновременно противоречит ему, а целое демонстрирует как славу божью, так и самоуверенную гордыню строителей.
      На этом фоне архитектурное единство Реймского собора производит, по контрасту, особенно сильное впечатление. Радость, которую испытывает зритель, вызвана в равной мере как единством проекта, так и отдельными его достоинствами. Как говорит путеводитель, этого единства удалось достичь благодаря самоотречению восьми поколений строителей, каждое из которых какую-нибудь свою идею приносило в жертву чистоте замысла. Результат провозглашает не только величие бога, но и величие людей, сумевших преодолеть свою гордыню.
      Хотя создание систем программирования и не занимает несколько столетий, почти все они страдают отсутствием концептуального единства, причем в гораздо большей степени, нежели соборы. Обычно это вызвано не последовательной сменой главных разработчиков, а разбиением проекта на множество частей, выполняемых многими людьми.
      Я продолжаю настаивать на том, что концептуальное единство является самым важным соображением при проектировании системы. Лучше иметь систему, не имеющую некоторых не слишком существенных свойств, но воплощающую в единое целое множество концепций проектирования, чем систему, содержащую много хороших, но независимых и нескоординированных идей.
      В этой и двух последующих главах мы рассмотрим именно эту сторону создания систем программирования и попытаемся ответить на вопросы:
      * Как добиться концептуального единства проекта?
      * Не подразумевает ли такая постановка проблемы деления на элиту, т. е. аристократов-архитекторов, и серую массу плебеев-программистов, творческие таланты и идеи которых всячески подавляются?
      * Как удержать архитектора от витанпя в облаках, от создания нереализуемых или просто дорогих спецификаций?
      * Как добиться того, чтобы каждая, даже незначительная деталь спецификации, сделанной архитектором, дошла до исполнителя, была им правильно осмыслена и нашла свое место в конечном продукте?
      Как добиться концептуального единства
      Система программирования предназначена для того, чтобы облегчить пользование вычислительной машиной. С этой целью создаются -машинные языки и другие различные средства, являющиеся по существу программами. Обращение к ним и управление ими тоже выполняется с помощью машинного языка. Но эти средства весьма дороги: внешнее описание системы программирования стоит в десять-двадцать раз больше, чем внешнее описание самой вычислительной системы. Пользователю гораздо легче самому определить любую требуемую функцию, чем выбрать ц запомнить множество вариантов, форматов и т. п.
      Пользование облегчается, если время, выигранное благодаря функциональным возможностям, больше времени, потерянного на изучение, запоминание и поиски в руководствах. В современных системах программирования этот выигрыш - больше затрат, хотя за последнее время отношение выигрыша к затратам уменьшилось в связи с появлением все более сложных функций. Я все еще вспоминаю, как просто было работать на машине IBM-650, даже без ассемблера и вообще без какого бы то ни было программного обеспечения.
      Поскольку простота пользования - основная цель при проектировании, то соотношение между функциональными возможностями и концептуальной сложностью является высшим критерием системного проекта. Ни функциональность, ни простота сами по себе не гарантируют его высокого качества.
      Заблуждения на этот счет распространены чрезвычайно широко. Создатели операционной системы OS/360 объявили ее лучшей из всех существующих на том основании, что она выполняет больше всех функций. Функциональные возможности, а не простота, всегда считались критерием ее качества. С другой стороны, система разделения времени для PDP-10 провозглашалась ее создателями наилучшей именно из-за ее простоты п немногочисленности идей, на которых она основывается. Однако по своим функциям система PDP-10 не может быть отнесена к тому же классу, что п OS/360. Коль скоро в качестве критерия выбирается простота в пользовании, то обе эти системы соответствуют идеалу только наполовину.
      На заданном уровне функциональных возможностей следует, однако, признать наилучшей ту систему, в которой различные задания выражаются с максимальной простотой п непосредственностью. Только простоты недостаточно. Язык TRAC, разработанный Муерсом, и алгол-68 достигли простоты, если ее измерять числом различных элементарных понятий. Однако они не обладают непосредственностью. Для выражения требуемых функций там зачастую используются весьма неожиданные и запутанные комбинации основных средств. Недостаточно выучить только элементы и правила их сочетания; необходимо знать также случаи идиоматического употребления, целый свод сведений о том, как элементы сочетаются на практике. Простота и непосредственность вытекают из концептуального единства. Каждая часть должна следовать одним п тем же принципам и одной и той же балансировке наших потребностей. Каждая часть должна использовать одну и ту же технику синтаксиса и одинаковые понятия в семантике. Таким образом, простота в пользовании диктует требования единообразия, т. е. концептуального единства при проектировании.
      Аристократия и демократия
      Концептуальное единство, в свою очередь, требует, чтобы весь проект исходил из одной головы, или же из нескольких, работающих в полном согласии.
      Однако график требует, чтобы система создавалась многими людьми. Существуют два метода решения этой дилеммы. Первый - это тщательное разделение труда между разработкой архитектуры и реализацией системы. Второй - это новый способ организации коллективов программистов, предложенный выше.
      Отделение архитектурных проблем от реализации является весьма эффективным путем достижения концептуального единства очень больших проектов. Я убедился в этом на примере успешного создания фирмой IBM вычислительной машины Stretch и промышленной серии ЭВМ Системы 360.
      Отсутствие такого подхода сказалось при разработке операционной системы OS/360.
      Под архитектурой системы я понимаю полную и подробную спецификацию ее сопряжения с пользователем. Для вычислительной машины это руководство по программированию. Для транслятора - руководство по входному языку. Для управляющей программы - руководство по одному или нескольким языкам, используемым для обращения к ее функциям. Для системы в целом - это объединение всех тех руководств, к которым должен обращаться пользователь, чтобы решить свою задачу.
      Архитектор системы, как и архитектор, проектирующий здание,- агент пользователя. Его работа заключается в том, чтобы использовать свои профессиональные и технические знания исключительно в интересах пользователя, в противоположность интересам коммивояжера, производителя и т. д.2).
      Необходимо тщательно отделять архитектуру от реализации. Как сказал Блау, "Там, где архитектура говорит, что происходит, разработка говорит, как это должно происходить"3). В качестве простого примера он приводит часы, архитектура которых - циферблат, стрелки и головка завода. Когда ребенок познакомится с этой архитектурой, он с одинаковой легкостью сможет определять время как по ручным часам, так и по башенным курантам. Разработка и реализация, однако, каждый раз описывают внутреннюю структуру механизмы, приводящие часы в действие и обеспечивающие точность хода.
      В Системе 360, например, одна машинная архитектура реализована совершенно по-разному в каждой из девяти моделей, и наоборот, одна реализация, средства обмена, память и микропрограммы модели 360/30 используются в четырех различных архитектурах: серия ЭВМ Системы 360, мультиплексный канал с 224 логическими независимыми подканалами, селекторный канал и вычислительная машина IBM-14014).
      Такое разграничение в равной степени применимо и к системам программирования. Существует стандартный фортран IV. Он является архитектурой для многих трансляторов. В рамках этой архитектуры возможны самые различные реализации: программа в оперативной памяти пли транслятор в оперативной памяти, быстрая трансляция или оптимизация, синтаксически ориентированный или "прямой" транслятор. Подобным образом любой язык ассемблера или язык управления задачами допускает разные реализации ассемблера или планировщика.
      Теперь мы обратимся к более эмоциональной стороне проблемы: аристократия против демократии. Разве не образуют архитекторы своего рода аристократию, интеллектуальную элиту, которая указывает разработчикам, что им следует делать? Не отбирает ли эта элита всю творческую работу, отводя разработчикам роль "винтиков"? Может быть, конечный продукт улучшится, если, следуя принципам демократии, позволить всему коллективу генерировать идеи, а не ограничиваться спецификациями, разработанными всего несколькими людьми?
      Последний вопрос самый легкий. Я, естественно, не собираюсь настаивать на том, что только у архитекторов могут быть хорошие архитектурные идеи. Довольно часто свежая мысль исходит от разработчика пли от пользователя. Однако весь мой опыт убеждает меня в том, что именно концептуальное единство системы определяет легкость ео использования, и я попытаюсь это показать. Предлагаемые средства и идеи сами по себе могут быть очень хороши, но если они не составляют единого целого с основными концепциями системы, от них лучше отказаться. Если же таких отличных, но несовместимых идей оказалось много, остается только выбросить в мусорную корзинку всю систему и заняться созданием новой, обладающей единством и построенной на других основных идеях.
      Что касается вопроса о появлении новой аристократии, то следует ответить и да, и нет.
      Да - в том смысле, что архитекторов всегда немного, а конечный продукт их деятельности живет дольше, чем результаты труда разработчиков, и архитектор находится в центре всех усилий по проектированию системы, защищая интересы пользователей. Если система должна обладать концептуальным единством, то необходим кто-то, следящий за этими концепциями. Это и есть та аристократия, которая не нуждается в извинениях.
      Нет - потому что разработка внешних спецификаций - ничуть не более творческая работа, чем разработка проектов. Просто это другая работа. Разработка проекта, если архитектура уже имеется, требует от исполнителей и позволяет им в той же мере проявлять творческие способности и выдавать новые идеи, как и создание внешних спецификаций. По существу отношение стоимости продукта к его производительности в основном зависит от разработчика, в то время как простота пользования зависит от архитектора.
      Существует множество примеров из других областей искусства и ремесла, заставляющих поверить в то, что дисциплина полезна. Как утверждает афоризм, распространенный среди художников, "форма освобождает". Хуже всего получаются сооружения, бюджет которых -больше, чем это нужно для достижения поставленной цели. Вряд ли необходимость каждую неделю писать по кантате отрицательно сказывалась на творческих возможностях Баха. Я уверен, что архитектура вычислительной машины Stretch много выиграла бы от введения более строгих ограничений; так, ограничения, накладываемые бюджетом модели 30 Системы 360, по моему мнению, положительно сказались на архитектуре модели 75. Аналогично я подметил, что заданная архитектура повышает, а не подавляет творческие возможности группы разработчиков. Они сразу же сосредоточиваются на той части проблемы, которой еще не занимались, и в результате появляются творческие находки. Если же на работу группы не накладывается никаких ограничений, то много времени и усилий, размышлений и обсуждений уйдет на архитектурные решения, а с самой реализацией они справятся очень быстро5).
      Существование этого эффекта, который я наблюдал неоднократно, подтверждает Р. Конвей - руководитель группы, создавшей транслятор PL/G с языка PL/I в Корнелльском университете. Он говорит: "В конце концов, мы решили реализовать язык без всяких изменений и улучшений, потому что дебаты по этому вопросу отняли бы у нас все силы"6).
      Чем может заполнить разработчик период ожидания?
      Ошибка, стоимостью в несколько миллионов долларов, служит очень горестным уроком, но запоминается надолго. Я живо помню тот вечер, когда мы принимали решение о написании внешних спецификации для OS/360. Руководитель группы архитекторов ЭВМ, руководитель отдела разработки управляющих программ и я бились над планом, графиком и распределением обязанностей.
      В группе архитекторов было 10 отличных специалистов. Ее руководитель утверждал, что они могут написать спецификации, и сделают это хорошо. Но на это потребуется 10 месяцев, на три месяца больше, чем допускал график.
      В отделе управляющих программ было 150 человек. Ее руководитель говорил, что, взаимодействуя с архитекторами, они смогут подготовить практичные спецификации высокого качества и при этом уложиться в график. Если же этим займутся архитекторы, то его 150 человек будут десять месяцев бить баклуши.
      На это архитектор отвечал, что если я поручу написание спецификаций отделу управляющих программ, то мы не только не дождемся результатов вовремя, но получим их на три месяца позже и они окажутся гораздо хуже. Так ц получилось. Архитектор был прав во всех отношениях. Кроме того, отсутствие концептуального единства увеличило стоимость создания и модификации системы п, по моим оценкам, удлинило срок отладки по меньшей мере па год.
      Много факторов, конечно, повлияло на принятие этого ошибочного решения, но главными были график п желание дать работу 150 разработчикам. Сирены пели мне именно эту песню, ц теперь-то я вижу всю ее смертельную опасность.
      Когда речь заходит о том, чтобы поручить маленькой группе архитекторов создание всех внешних спецификаций для вычислительной машины или системы программирования, разработчики выдвигают три возражения:
      * спецификации будут слишком разнообразны по функциям, но не учтут практическую стоимость реализации;
      * архитекторы сделают всю творческую часть работы, лишив разработчиков возможности что-либо придумать самим;
      * большому числу разработчиков придется простаивать, в то время как спецификации будут проходить через игольное ушко, называемое группой архитекторов.
      Первое представляет реальную опасность и подробнее будет рассматриваться в следующей главе. Два других возражения - не более, чем мираж. Как мы уже убедились, разработка - тоже творческая деятельность. Возможности для творчества и проявления изобретательности при разработке не уменьшаются сколько-нибудь значительно из-за необходимости работать с заданными внешними спецификациями, а степень проявления творческой активности может даже возрасти благодаря дисциплине. Конечный же продукт, вне всякого сомнения, от этого только выиграет.