Даже при ошибочном синтаксисе всегда получается некоторый результат; в контролируемой системе этот результат является указанием на ошибку и ничем больше. В неконтролируемой системе могут возникнуть любые побочные эффекты и быть использованы программистами. Когда мы, например, эмулировали IBM 1401 на System/360, выявилось 30 различных "курьезов" - побочных эффектов предположительно незаконных операций, которые широко использовались и должны были быть признаны частью определения. Реализация в качестве определения возобладала. Она не только говорила о том, что должна делать машина, но и многое сказала о том, как машина не должна была это делать.
Кроме того, на проницательные вопросы реализация иногда дает неожиданные ответы, и определение де-факто часто оказывается неизящным в этих особых случаях потому, что над ними никогда не задумывались. Копирование этой неэлегантности в другой реализации часто оказывается замедляющим или дорогостоящим. Например, в некоторых машинах в регистре множимого после умножения остается мусор. Точная природа этого мусора становится частью определения де-факто, однако его копирование может помешать использованию более быстрого алгоритма умножения.
Наконец, использование реализации в качестве формального определения может создать неясность, какое из описаний - текстовое или формальное - в действительности является стандартом. Это относится особенно к программным моделям. Следует также воздерживаться от внесения изменений в реализацию, пока она служит в качестве стандарта.
Прямое включение
У архитекторов программных систем есть чудесный метод распространения и внедрения определений. Он особенно полезен при установлении если не семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в создании объявлений передаваемых параметров или совместно используемой памяти и требовании включения этих объявлений при операциях времени компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на интерфейс происходят только по символическим именам, объявления можно менять, добавляя или вставляя новые имена и лишь заново компилируя, но не изменяя использующую его программу.
Конференции и суды
Нет нужды говорить о том, что совещания необходимы. Сотни частных консультаций должны дополняться крупными и более формальными собраниями. Мы признали полезными два уровня таких собраний. Первый - это еженедельная конференция всех архитекторов вместе с официальными представителями разработчиков аппаратной и программной части и сотрудниками маркетинга продолжительностью в половину рабочего дня под председательством главного архитектора системы.
Предлагать задачи и изменения можно всем, но обычно предложения распространяются в письменном виде до совещания. Обычно новая задача некоторое время обсуждается. Упор делается на творческой стороне, а не просто на принятии решения. Группа пытается предложить несколько решений проблемы, затем ряд предложенных решений передается одному или нескольким архитекторам для разработки подробных и точно сформулированных предложений по внесению изменений в руководство.