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

Я обычно покупаю компьютеры и программы, проверяя их на «счастливом обладателе», т.е. беседуя с вызывающими доверие людьми, заплатившими деньги за продукт и пользующимися им с удовольствием. Аналогично, я с готовностью поверю в материализацию серебряной пули, когда вызывающий доверие независимый пользователь выступит вперед и скажет: «Я использовал эту методологию, этот инструмент или продукт, и это позволило мне в десять раз повысить производительность разработки программ».

Многие корреспонденты сделали верные поправки и разъяснения. Некоторые проанализировали статью пункт за пунктом и привели возражения, за что я им благодарен. В этой главе я хочу сообщить о сделанных поправках и ответить на опровержения.

Неясное изложение влечет непонимание

Судя по некоторым откликам, мне не удалось четко изложить свои аргументы.

Второстепенное свойство (accident). В резюме главы 16 я постарался со всей возможной ясностью изложить основные аргументы «СПН». Некоторые, однако, были смущены терминами второстепенное свойство (accident) и несущественный, второстепенный (accidental), которые я использовал в старом употреблении, восходящем к Аристотелю. [4] Под accidental я не имел в виду «случайный» или «относящийся к несчастному случаю», а скорее, «несущественный», «побочный» (incidental) или «принадлежащий» (appurtinent).

Я не хочу порочить роль случайности при разработке программ. Вслед за английским драматургом, автором детективов и теологом Дороти Сэйерс (Dorothy Sayers) я рассматриваю всякую творческую деятельность, как состоящую из: а) формулирования концептуальных конструкций, б) воплощения в реальном материале и в) диалога с пользователем в реальной жизни. [5] Та часть построения программы, которую я назвал сущностью (essence), состоит из умственной работы создания концепутальной конструкции, а та, которую я назвал второстепенной (accident), есть процесс ее воплощения.

Выяснение истины. Мне кажется (хотя не все со мной согласны), что верность центрального аргумента сводится к выяснению ответа на вопрос: какая доля затрат связана с точным и упорядоченным представлением концептуальной конструкции, а какая — с умственными усилиями по изготовлению этих конструкций. Поиск и устранение ошибок попадают в тот или иной раздел в зависимости от того, являются ли ошибки концептуальными (например, пропуск какого-либо особого случая) или ошибками представления (например, ошибка в указателе или распределения памяти).

Мое личное мнение состоит в том, что второстепенная или направленная на представление часть работы сейчас снизилась до половины или менее того от общего объема. Поскольку эта доля является экспериментальной величиной, ее значение, в принципе, можно получить путем измерений. [5] Если это не удается, мою оценку можно поправить на основе более полных и более современных данных, но ни в публичных, ни в частных заявлениях никто не утверждал, что неосновная часть достигает величины 9/10.

«СПН» с несомненностью доказывает, что если доля неосновной части работы меньше 9/10, то даже сведя ее к нулю (что было бы чудом), нельзя получить рост продуктивности на порядок. Атаку необходимо нацелить на существенную часть.

После появления «СПН» Брюс Блум (Bruce Blum) обратил мое внимание на работу 1959 года Герцберга, Мознера и Зейдермана (Herzberg, Mausner, Sayderman). [7] Они находят, что факторы мотивации могут увеличить производительность. С другой стороны, факторы окружения и второстепенные факторы, сколь бы они ни были положительны, не могут этого сделать, но, будучи отрицательными, могут уменьшить производительность. В «СПН» доказывается, что значительная часть прогресса в программной инженерии достигнута за счет устранения влияния следующих отрицательных факторов: крайне неудобных машинных языков, пакетной обработки с долгой оборачиваемостью, слабого инструментария и строгих ограничений на размер памяти.

Являются ли в таком случае безнадежными трудности, связанные с сущностью? Отличная работа «Серебряная пуля есть», написанная Бредом Коксом (Bred Cox) в 1990 году, красноречиво доказывает, что многократно используемые и взаимозаменяемые компоненты должны послужить основой для атаки на концептуальную сущность проблемы. [8] Я охотно соглашаюсь.

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

Сложность разделения на уровни. Например, наиболее серьезной внутренней трудностью является сложность, но она не всегда неизбежна. Значительная часть (но не вся) концептуальной сложности в наших программных конструкциях проистекает от произвольной сложности самих применений. Действительно, Ларс Седаль из MYSYGMA Sohdal and Partners, международной консалтинговой фирмы в области менеджмента, пишет:

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

Стив Лукашик (Steve Lukasik) из Northrop доказывает, что даже организационная сложность, возможно, не является произвольной, а может испытывать воздействие принципов упорядочения:

Я получил образование в облати физики и поэтому вижу, что «сложные» вещи могут быть описаны на языке более простых понятий. Вы можете быть правы, и я не стану утверждать, что все сложные вещи поддаются принципам упорядочения… по тем же правилам доказательства нельзя утверждать, что не поддаются.

…То, что вчера было сложностью, завтра будет в порядке вещей. Сложность беспорядочного движения молекул привела к возникновению кинетической теории газов и открытию трех законов термодинамики. Сейчас программное обеспечение не позволяет увидеть присущие ему принципы упорядочения, но вы как раз и должны объяснить, почему это происходит. Это не проявление моей бестолковости или желания поспорить. Я убежден, что в один прекрасный день «сложность» программного обеспечения будет объяснена на языке каких-нибудь понятий более высокого порядка (инвариантов, как говорят физики).

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

Значительно большая часть сложности программных конструкций обусловлена, однако, не соответствием внешнему миру, а самой реализацией — структурами данных, алгоритмами, способами коммуникаций. Наращивание программ с помощью больших блоков высокого уровня, созданных когда-то раньше или кем-то другим, помогает избежать целых уровней сложности. «СПН» провозглашает поход на проблему сложности в полной надежде, что можно достичь прогресса. Она выступает за добавление к программной системе необходимой сложности:

• иерархически, располагая модули или объекты по уровням;

• пошагово, что обеспечивает постоянную работоспособность системы.

Анализ Харела

Дэвид Харел (David Harel) в статье 1992 года «Кусая серебрянную пулю» предпринимает самый тщательный анализ «СПН» из всех опубликованных. [9]

Пессимизм против оптимизма и реализма. Харел рассматривает как «СПН», так и статью Парнаса 1984 года «Программные аспекты стратегических оборонительных систем» [10] как «слишком унылые». Он намеревается высветить более яркую сторону проблемы, предпосылая статье подзаголовок «К светлому будущему порграммных разработок». Так же, как и Кокс, Харел считает «СПН» пессимистической, говоря: «Если взглянуть на те же факты с другой точки зрения, возникают более оптимистические выводы». Оба они неправильно воприняли тональность статьи.