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

Что касается выбора в качестве периода предсказаний 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 для космического челнока.