Однако Кокс неправильно понимает "СПН" в двух отношениях. Во-первых, он находит в ней утверждение того, что трудности разработки программного обеспечения проистекают из "некоторых порогов технологий, использовавшихся программистами в то время". Я же доказывал, что трудности, связанные с сущностью, являются неотъемлемой частью концептуальной сложности разрабатываемых программных функций во все времена и при любых методах. Во-вторых, он и многие другие прочли в "СПН" утверждение того, что нет никаких надежд успешно справиться со сложностями разработки программ, связанными с вопросами сущности. Это не то, что я имел в виду. Создание концептуальной конструкции действительно имеет внутренне присущие трудности, такие как сложность, согласованность, изменяемость и незримость. Однако неприятности, вызываемые всеми этими трудностями, можно уменьшить.
Сложность разделения на уровни. Например, наиболее серьезной внутренней трудностью является сложность, но она не всегда неизбежна. Значительная часть (но не вся) концептуальной сложности в наших программных конструкциях проистекает от произвольной сложности самих применений. Действительно, Ларс Седаль из MYSYGMA Sohdal and Partners, международной консалтинговой фирмы в области менеджмента, пишет:
Мой опыт показывает, что все сложности, с которыми сталкиваются при разработке систем, являются признаками организационных неполадок. Попытка моделирования практической деятельности программами соответствующей сложности влечет сохранение неразберихи вместо решения проблем.
Стив Лукашик (Steve Lukasik) из Northrop доказывает, что даже организационная сложность, возможно, не является произвольной, а может испытывать воздействие принципов упорядочения:
Я получил образование в облати физики и поэтому вижу, что "сложные" вещи могут быть описаны на языке более простых понятий. Вы можете быть правы, и я не стану утверждать, что все сложные вещи поддаются принципам упорядочения… по тем же правилам доказательства нельзя утверждать, что не поддаются.
…То, что вчера было сложностью, завтра будет в порядке вещей. Сложность беспорядочного движения молекул привела к возникновению кинетической теории газов и открытию трех законов термодинамики. Сейчас программное обеспечение не позволяет увидеть присущие ему принципы упорядочения, но вы как раз и должны объяснить, почему это происходит. Это не проявление моей бестолковости или желания поспорить. Я убежден, что в один прекрасный день "сложность" программного обеспечения будет объяснена на языке каких-нибудь понятий более высокого порядка (инвариантов, как говорят физики).
Я не занимался более глубоким анализом, к которому справедливо призывает Лукашик. Как отрасль науки мы нуждаемся в развитии теории информации для количественной оценки информационного содержания статистических структур, подобно тому, как теория Шэннона делает это для информационных потоков. Это совсем не моя задача. Лукашику я просто отвечу, что сложность системы является функцией мириадов деталей, каждая из которых должна быть точно задана либо с помощью какого-нибудь общего правила, либо подробным описанием, но не просто статистически. Представляется весьма сомнительным, чтобы несогласованные результаты работы многих голов оказались достаточно связными, чтобы быть точно описанными общими правилами.
Значительно большая часть сложности программных конструкций обусловлена, однако, не соответствием внешнему миру, а самой реализацией - структурами данных, алгоритмами, способами коммуникаций. Наращивание программ с помощью больших блоков высокого уровня, созданных когда-то раньше или кем-то другим, помогает избежать целых уровней сложности. "СПН" провозглашает поход на проблему сложности в полной надежде, что можно достичь прогресса. Она выступает за добавление к программной системе необходимой сложности:
• иерархически, располагая модули или объекты по уровням;
• пошагово, что обеспечивает постоянную работоспособность системы.
Анализ Харела
Дэвид Харел (David Harel) в статье 1992 года "Кусая серебрянную пулю" предпринимает самый тщательный анализ "СПН" из всех опубликованных.[9]
Пессимизм против оптимизма и реализма. Харел рассматривает как "СПН", так и статью Парнаса 1984 года "Программные аспекты стратегических оборонительных систем"[10]как "слишком унылые". Он намеревается высветить более яркую сторону проблемы, предпосылая статье подзаголовок "К светлому будущему порграммных разработок". Так же, как и Кокс, Харел считает "СПН" пессимистической, говоря: "Если взглянуть на те же факты с другой точки зрения, возникают более оптимистические выводы". Оба они неправильно воприняли тональность статьи.
Прежде всего, моя жена, коллеги и редакторы считают, что я гораздо чаще впадаю в неоправданный оптимизм, чем в пессимизм. В конце концов я по происхождению программист, а оптимизм - это профессиональная болезнь данного ремесла.
В "СПН" прямо сказано: "Вглядываясь в предстоящее десятилетие, мы не видим серебряной пули… Однако скептицизм не есть пессимизм… Нет царского пути, но путь есть". Она предсказывает, что нововведения, происходящие в 1986 году, будучи разработаны и использованы, в совокупности действительно позволят достичь роста производительности на порядок. Десятилетие 1986-1996 подходит к концу, и это предсказание оказывается, скорее, слишком оптимистичным, а не мрачным.
Даже если бы все без исключения считали "СПН" пессимистической, что в этом худого? Является ли утверждение Эйнштейна о том, что ничего не может перемещаться со скоростью, большей скорости света, "унылым" и "мрачным"? А как насчет результатов Геделя о том, что некоторые вещи невычислимы? "СПН" пытается утверждать, что "сама сущность программного обеспечения делает маловероятным открытие "серебряных пуль" когда-либо в будущем". Турский в своем отличном ответном докладе на конференции IFIP красноречиво заявил:
Из всех попыток науки продвинуться в ложном направлении наиболее возвышенны те, которые были направлены на поиск философского камня - вещества, с помощью которого предполагалось обращать простые металлы в золото. Высшая цель алхимии, к которой с рвением стремились поколения исследователей, щедро финансировавшиеся светскими и духовными правителями, - это в чистом виде стремление принимать желаемое за действительное и общепринятое мнение, что вещи таковы, какими мы хотели бы их видеть. Это очень по-человечески. Нужно сделать над собой большое усилие, чтобы смириться с существованием неразрешимых проблем. Стремление вопреки всему найти выход, даже когда доказано, что его не существует, очень и очень сильно. И в большинстве своем мы с большим сочувствием относимся к этим храбрецам, которые пытаются достичь невозможного. Это продолжается и по сей день. Пишутся сочинения о квадратуре круга. Стряпаются лосьоны для восстановления утраченных волос - и неплохо продаются. Рождаются методы повышения производительности программирования - и хорошо расходятся.
Мы слишком часто склонны доверять своему оптимизму (или эксплуатировать оптимистические надежды своих спонсоров). Мы слишком часто не хотим прислушиваться к голосу рассудка и обращаем много внимания на продавцов панацей, поющих голосами сирен.[11]
Турский, как и я, предупреждает, что мечтательность тормозит движение вперед и ведет к пустой трате сил.
"Мрачные" темы. Харел считает, что мрачность "СПН" придают три темы:
• Резкое разделение между сущностью и второстепенным.
• Изолированное рассмотрение каждого кандидата в "серебряные пули".
• Прогноз лишь на ближайшие 10 лет, а не на срок, в течение которого можно ожидать "существенных улучшений".
Что касается первого, то в это вся соль статьи. Я по-прежнему считаю, что такое разделение необходимо для понимания того, почему трудно создавать программное обеспечение. И это верное указание, куда должен быть направлен удар.
Что касается изолированного рассмотрения кандидатов в "серебряные пули", то это
правда. Разные кандидаты предлагались поочередно и непомерными претензиями на
собственное всесилие. Правомерно и рассматривать их поочередно. Я возражаю не
против самих технологий, но против ожидания от них чуда. Гласс, Весси и Конджер
(Glass, Vessey, Conger) в своей статье 1992 года представили многочисленные
свидетельства того, что бесполезные поиски серебряной пули все еще продолжаются.[12]
Что касается выбора в качестве периода предсказаний 10, а не 40 лет, то частично это признание того, что наши предсказания на больший срок никогда не были удачными. Кто из нас в 1975 году предсказал микрокомпьютерную революцию 80-х?
Есть и другие причины ограничиться десятилетием: все кандидаты претендовали на получение результатов немедленно. Я не помню ни одного, который бы сказал: "Если сегодня вы сделаете инвестиции в предлагаемое мной средство, то по прошествии 10 лет начнете пожинать плоды". Более того, за десятилетие соотношение производительность/цена для компьютеров выросло, наверное, в сотни раз, и неизбежно подсознательно производится сравнение, которое совершенно недопустимо. Мы наверняка достигнем большего прогресса за предстоящие 40 лет. Рост за 40 лет на порядок едва ли покажется чудом.
Мысленный эксперимент Харела. Харел предлагает мысленный эксперимент, в котором "СПН" была написана в 1952 году, а не в 1986, но содержала бы те же утверждения. Он хочет использовать это в качестве доказательства от противного в борьбе против попыток отделить сущность от акциденции.
Это доказательство неверно. Во-первых, "СПН" начинается с утверждения, что для программирования в 1950-х характерно значительное преобладание трудностей в акциденциях над трудностями в сущности. Этого преобладания больше не существует, что привело к росту производительности на порядки величин. Переносить это доказательство на 40 лет назад бессмысленно: никто не стал бы в 1952 году утверждать, что не трудности акциденций ответственны за большую часть затрачиваемых усилий.
Во-вторых, Харел неточно представляет положение дел в 1950-х:
Это было время, когда вместо того, чтобы разрабатывать большие сложные системы, программисты писали обычные однопользовтельские программы, которые на современных языках программирования заняли бы 100-200 строк, и которые должны были выполнять скромные алгоритмические задачи. При существовавших тогда технологиях и методологиях такие задачи тоже были очень трудными. Сплошь и рядом были неудачи, ошибки, нарушение сроков.
Затем он описывает, как за последние 25 лет упомянутые неудачи, ошибки, нарушенные сроки в обычных маленьких одновользовательских программах были улучшены на порядок.
Но в действительности в 1950-х годах вершиной технологии были не маленькие однопользовательские программы. В 1952 году Univac был занят обработкой данных переписи 1950 года с помощью сложной программы, которую разрабатывали примерно восемь программистов.[13]Другие машины применялись в химической динамике, расчетах рассеяния нейтронов, расчетах полета ракет и т.д.[14]Повседневно использовались ассемблеры, перемещающие компоновщики и загрузчики, системы интерпретации с плавающей точкой и т.п.[15]
К 1955 году уже создавались программы для бизнеса объемом от 50 до 100 человеко-лет.[16]В 1956 году на заводе Дженерал Электрик в Льюисвилле работала программа размером более 80 000 слов. В 1957 году в течение уже двух лет в системе противовоздушной обороны работал компьютер SAGE ANFSQ/7, и на 30 площадках действовала система реального времени, использовавшая телекоммуникации и дублирование в целях отказоустойчивости, объемом 75 000 команд.[17]Едва ли можно придерживаться мнения, что развитие технологий для однопользовательских программ - главная характеристика усилий в технике программного обеспечения после 1952 года.
ВОТ ОНА. Харел продолжает, предлагая собственную серебряную пулю, технологию моделирования под названием "Vanilla Framework" ("ванильная структура"). Сам подход описан недостаточно подробно, чтобы его можно было оченить, но есть ссылка на статью и технический отчет, который в свое время должен быть опубликован в виде книги.[18]Моделирование касается сущности, правильной разработки и отладки понятий, поэтому технология может оказаться революционной. Надеюсь, что это так. Кен Брукс сообщает, что эта методология оказалась полезной, когда он попытался применить ее к реальной задаче.
Незримость. Харел энергично доказывает, что значительная часть концептуальной конструкции программного обеспечения является по своей природе топологической задачей, и эти взаимосвязи находят соответствие в пространственно-графических представлениях:
Использование подходящего визуального формализма может оказать заметное воздействие на инженеров и программистов. Более того, это воздействие не ограничивается областью акциденций, было обнаружено положительное влияние на качество и быстроту самого их мышления. В будущем успехи в разработке систем будут связаны с визуальными представлениями. Сначала мы будем создавать концепции с помощью "правильных" объектов и взаимосвязей, затем формулировать наши концепции как последовательный ряд все более обстоятельных моделей с использованием подходящей комбинации визуальных языков. Именно комбинации, поскольку модели систем имеют несколько граней, каждая из которых вызывает в воображении различные виды образов.
…Некоторые грани процесса моделирования не столь легко поддаются хорошей визуализации. Например, алгоритмические операции над переменными и структурами данных, возможно, останутся текстуальными.
Здесь наши позиции близки. Я доказывал, что структура программного обеспечения не является трехмерной, поэтому не существует естественного отображения концептуального проекта в диаграмму в пространстве как двух, так и большего числа измерений. Харел допускает, и я согласен, что требуется много диаграмм, каждая из которых охватывает какую-то одну сторону, а некоторые аспекты вообще плохо отображаются на диаграммах.
Я вполне разделяю его энтузиазм по поводу использования диаграмм как вспомогательного средства при обдумывании и проектировании. Долгое время я любил задавать кандидатам на работу программистом вопрос: "Где находится следующий ноябрь?". Если вопрос кажется загадочным, то в другом виде: "Какова ваша мысленная мысленная модель календаря?" У действительно хороших программистов хорошее чувство пространства, у них обычно есть геометрическая модель времени, и они часто без труда понимают первый вопрос. Их модели очень индивидуальны.
Точка зрения Джонса: производительность приходит вслед за качеством
Каперс Джонс (Capers Jones) сначала в серии служебных записок, а затем в отдельной книге демонстрирует глубокую интуицию, отмеченную несколькими моими корреспондентами. "Статья "СПН", как и многие в то время, сосредоточилась на производительности - выходе программной продукции на единицу входных затрат", - говорит Джонс. - "Нет, сосредоточьтесь на качестве, а производительность придет следом."[19]Он утверждает, что дорогостоящие и нарушившие сроки проекты требуют больше всего дополнительных усилий и времени для поиска и устранения ошибок в спецификациях, в проекте, в разработке. Он приводит данные, свидетельствующие о сильной корреляции между отсутствием систематического контроля качества и срывом графика работ. Я им вполне верю. Бём (Boehm) указывает, что производительность снова падает, когда преследуется исключительно высокое качество, как было в программах IBM для космического челнока.
Аналогичным образом, Коки (Coqui) утверждает, что принципы систематической разработки программного обеспечения явились ответом на озабоченность не столько производительностью, сколько качеством (в особенности, стремлением избежать крупных катастроф).
Но обратите внимание: целью применения инженерных принципов к разработке программного обеспечения в 1970-х годах было поднять качество, тестируемость, устойчивость и предсказуемость программных продуктов, а не обязательно производительность труда программистов.
Движущей силой использования при разработке программ принципов программной инженерии было опасение крупных аварий, к которым могла привести разработка все более сложных систем неуправляемыми художниками.[20]
Так что же случилось с производительностью?
Производительность в цифах. Цифры, характеризующие производительность, очень тяжело определить, калибровать и найти. Каперс Джонс считает, что для двух одинаковых программ на Cobol, написанных с интервалом в 10 лет - с применением структурного программирования и без него - разница в производительности троекратная.
Эд Йордон (Ed Yourdin) утверждает: "По моим наблюдениям, благодаря рабочим станциям и программным инструментам производительность увеличилась в пять раз." Том Демарко (Tom DeMarco) считает, что "ваше ожидание десятикратного роста производительности за 10 лет благодаря целому набору технологий было оптимистичным: мне неизвестны организации, добившиеся роста
производительности на порядок."
Программа в упаковке: покупайте, не надо разрабатывать. Одна из оценок "СПН" оказалась, я думаю, правильной: "Возникновение массового рынка является… наиболее глубокой долгосрочной тенденцией в разработке программного обеспечения". С точки зрения науки, программное обеспечение для массового рынка образует практически новую отрасль в сравнении с разработкой заказных программ как внутри фирмы, так и сторонними организациями. Когда счет проданных пакетов идет на миллионы или хотя бы на тысячи, главными проблемами становятся качество, своевременность, технические характеристики и стоимость поддержки, а не стоимость разработки, которая имеет такое большое значение при разработке заказных систем.
Электроинструмент для ума. Лучший способ повысить производительность труда программистов информационно-управляющих систем - это пойти в ближайший компьютерный магазин и купить уже готовым то, что они собираются разработать. Это не шутка: доступность дешевых и мощных коробочных программ удовлетворила многие из потребностей, ранее удовлетворявшихся заказными программами. Эти электроинструменты для ума больше похожи на электрическте дрели, пилы и шлифовальные машины, чем на большие и сложные производственные станки. Интеграция их в совместимые и перекрестно-связанные наборы, такие как Microsoft Works или лучше интегрированный ClarisWorks, обеспечивает огромную гибкость. И подобно домашней коллекции инструмента, в результате частого использования набольшого набора для разных задач вырабатываются привычные навыки. Такой инструмент подчеркивает простоту использования обычным пользователем, даже не профессионалом.
Иван Селин (Ivan Selin), глава American Management Systems писал мне в 1987 году: