Во-вторых, Харел неточно представляет положение дел в 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 году:
      Я хочу придраться к вашему утверждению, что в действительности пакеты не настолько изменились… Я думаю, что вы слишком легко отбросили главные следствия вашего замечания, что (программные пакеты) «могут быть немного более общими и немного лучше настраиваемыми, чем раньше, но не намного». Даже принимая это заявление за чистую монету, я полагаю, что пользователи расценивают пакеты, как обладающие более широкими возможностями и легче настраиваемые, и что такое восприятие делает пользователей более податливыми перед пакетами. В большинстве случаев, известных моей компании, не программисты, а (конечные) пользователи неохотно пользуются пакетами, покскольку думают, что лишатся важных возможностей и функций, а потому возможность легкой настройки весьма повышает для них привлекательность продукта.
      Я думаю, что Селин совершенно прав: я недооценил как степень настраиваемости пакета, так и важность этого фактора.
       Объектно-ориентированное программирование: а медна пуля не подойдет?
      Разработка из больших частей. Если осуществлять сборку из частей, которые достаточно сложны и имеют однородные интерфейсы, можно быстро образовывать довольно богатые структуры.
      Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляет модульность и чистые интерфейсы. Другая точка зрения подчеркивает инкапсуляцию — невозможность увидеть и еще менее изменить внутреннюю структуру детали. Еще одна точка зрения отмечает наследование и сопутствующую ему иерархическую структуру классов с виртуальными функциями. И еще один взгляд: важнейшей является сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип данных будет обрабатываться только применимыми к нему операциями.
      В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины: одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция.
      Почему объектно-ориентированная технология медленно развивалась? В течение девяти лет после выхода «СПН» надежды неуклонно росли. Почему развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение четырех лет ведущий колонку в The C++ Report, дает такое объяснение:
      Проблема в том, что программисты, работающие в ООП, экспериментировали с кровосмесительными приложениями и были нацелены на низкий уровень абстракции. Например, они строили такие классы, как «связанный список» вместо «интерфейс пользователя», или «луч радиации», или «модель из конечных элементов». К несчастью, строгая проверка типов, которая помогает программистам C++ избегать ошибок, одновременно затрудняет построение больших объектов из маленьких. [21]
      Он возвращается к фундаментальной проблеме программирования и доказывает, что один из способов удовлетворить потребность в программном обеспечении — увеличить численность образованной рабочей силы путем подготовки и привлечения наших клиентов. В пользу нисходящего проектирования приводятся такие аргументы:
      Если мы проектируем крупные классы, представляющие концепции, с которыми наши клиенты уже работают, то они в состоянии понимать и критиковать проект по мере его развития, а также вместе с нами разрабатывать контрольные примеры. Офтальмологов, с которыми я работаю, не волнует организация стека; их волнует описание формы роговицы с помощью полиномов Лежандра. Маленькая инкапсуляция дает и маленькую выгоду.
      Дэвид Парнас, чья статья была одним из источников идей объектно-ориентированного программирования, смотрят на вещи по иному. Он писал мне:
      Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определенного инструмента. Любыми срадствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдет в моду.
      Расходы сейчас, прибыль потом. По моему мнению, у объектно-ориентированных методологий особенно тяжелый случай болезни, характерной для многих усовершенствований в методологии. Весьма существенны предварительные издержки — в основном, чтобы научить программистов мыслить совершенно по новому, а также на преобразование функций в обобщенные классы. Выгоды, которые я считаю реальными, а не чисто предположительными, достигаются во время всего цикла разработки, но настоящая окупаемость происходит при разработке последующих программ, расширении и сопровождении. Коггинс коворит: «Объектно-ориентированное программирование не ускорит разработку первого проекта, так же как и второго. А вот пятый проект из того же семейства будет сделан очень быстро.» [22]
      Рисковать реальными начальными деньгами ради предполагаемых, но неопределенных прибылей в будущем — это то, чем инвесторы занимаются изо дня в день. Однако во многих программирующих организациях менеджерам требуется для этого смелость — качество более редкое, чем компетенция в технических вопросах или административное мастерство. Я полагаю, что крайняя степень авансироания расходов и откладывания прибыли является самым существенным фактором, замедляющим принятие О-О технологий. Но даже в таких условиях C++, похоже, уверенно вытесняет C во многих организациях.
       Что с повторным использованием?
      Лучший способ справиться с разработкой части программной системы, относящейся к ее сущности — это вообще ее не разрабатывать. Пакеты программ — один из способов сделать это. Другой способ — повторное использование. Действительно, одной из наиболее привлекательных черт объектно-ориентированного программирования является обещание простоты повторного использования классов в сочетании с легкостью настройки благодаря наследованию.
      Как часто бывает, после получения некоторого опыта работы по новой технологии обнаруживается, что она не так проста, как казалось на первый взгляд.
      Конечно, программисты всегда повторно использовали собственные разработки. Джонс пишет:
      У наиболее опытных программистов есть свои личные библиотеки, позволяющие им при разработке новых программ повторно использовать до 30% кода по объему. На корпоративном уровне повторное использование приближается к 75% по объему и требует специальных библиотек и администрирования. Повторное использование кода в корпоративных масштабах требует изменений в бухгалтерии проекта и методах измерения работы. [23]
      У. Хуан (W. Huang) предложил организацию программного производства с матричной структурой управления функциональными специалистами, чтобы держать под контролем их естественную склонность к повторному использованию собственного кода. [24]
      Ван Шнайдер (Van Snyder) из JPL напоминает мне, что в кругах разработчиков математического программного обеспечения существует давняя традиция повторного использования программ:
      Мы полагаем, что препятствия к повторному использованию возникают не со стороны производителя, а со стороны потребителя. Если разработчик программного обеспечения — потенциальный потребитель стандартных программных компонентов — считает, что найти и проверить нужный компонент дороже, чем написать его заново, значит, будет написан новый компонент, дублирующий прежний. Обратите внимание, мы сказали «считает» — реальная стоимость повторной разработки не имеет значения.
      Повторное использование кода имеет успех при разработке математических программ. Причин этому две: 1) это магия, требующая огромного интеллектуального вклада в каждую строчку кода, и 2) существует богатая и стандартная терминология, а именно — математика, для описания функциональности любых компонентов. Поэтому повторно разработать математический компонент стоит дорого, а разобраться в функциональности стоит дешево. Давняя традиция публикации и сбора алгоритмов профессиональными журналами и предложения их по умеренной цене, а также коммерческое предложение высококачественных алгоритмов по несколько более высокой, но все же скромной цене, делают поиск требуемых компонентов проще, чем в других областях, где часто невозможно точно и сжато описать требуемое. Благодаря совместному действию этих факторов повторное использование математических программ более привлекательно, чем повторное их изобретение.
      Такое же явление повторного использования обнаруживается и в других сообществах, например, в разработке программ для атомных реакторов, моделирования климата, моделирования океанов — по тем же самым причинам. Каждое из этих сообществ выросло на одних и тех же учебниках, с одной и той же системой обозначений.
      **Как сегодня обстоят дела с повторным использованием на корпоративном уровне? Проведено множество исследований, а вот практикуется в США относительно мало. Что же касается повторного использования за рубежом, то тут имеют место неправдоподобные отчеты. [25]
      Джонс сообщает, что все клиенты его фирмы, у которых более 5000 программистов, проводят формальные исследования повторной используемости, в то время как из числа клиентов с 500 и менее программстами это делает менее 10 процентов. [26] По его сообщению, в отраслях с высоким потенциалом повторного использования исследования (не реализация) «ведутся активно и энергично, даже если не вполне успешно». Эд Йордон сообщает о программной фирме в Маниле, в которой 50 программистов из общего числа 200 заняты только разработкой повторно используемых модулей для использования всеми остальными, и что в тех случаях, которые он видел, принятие этой технологии было вызвано организационными, а не техническими факторами — например, системой поощрений.
      Демарко сообщает мне, что наличие массовых рыночных пакетов и возможность предоставления ими общих функций, таких как системы баз данных, существенно снизили как настоятельность, так и предельную полезность повторного использования модулей собственных приложений. «Повторно используемые модули имели тенденцию в конце концов становиться общими функциями.»
      Парнас пишет следующее:
      Повторное использование — это то, о чем легче говорить, чем осуществить. Для него требуются как хорошее проектирование, так и очень хорошая документация. Даже когда мы видим хорошее проектирование, что по-прежнему не часто, без хорошей документации компоненты не будут использоваться повторно.
      Кен Брукс сообщает, что трудно рассчитать, какая степень обобщенности окажется необходимой: «Мне приходится менять вещи, даже в пятый раз используя собственную библиотеку пользовательских интерфейсов.»
      Реально повторное использование только начинается. Джонс сообщает, что на открытом рынке есть несколько модулей с повторно используемым кодом по цене от 1 до 20 процентов от обычной стоимости разработки. [27] Демарко говорит:
      Меня все более обескураживает вся эта история с повторным использованием. Практически отсутствует теорема существования для повторного использования. Время подтвердило, что сделать вещи повторно используемыми стоит дорого.
      Йордон дает оценку того, сколько это стоит: «Хорошее эмпирическое правило говорит, что повторно используемые компоненты потребуют вдвое больших затрат, чем «одноразовые» компоненты.» [28] Я рассматриваю эту цену как величину затрат на запуск компонентов в производство, обсуждавшуюся в главе 1, поэтому я оцениваю рост затрат как троекратный.
      Конечно, мы видим различные формы и варианты повторного использования, но оно далеко не так широко применяется, как мы предполагали. Предстоит еще многое понять.
       Понимание больших словарей: неожиданная проблема повторного использования, которую можно было предвидеть
      Чем выше уровень, на котором осуществляется мышление, тем более многочисленны примитивные составляющие мысли, с которыми приходится иметь дело. Так, языки высокого уровня гораздо сложнее машинных языков, а естественные языки еще более сложны. У языков высокого уровня больше словари, более сложный синтаксис и более строгая семантика.
      Как научная дисциплина, мы не взвесили последствия этого факта для повторного использования программ. Чтобы повысить качество и производительность, мы хотим строить программы из частей с отлаженными функциями, которые существенно выше по уровню, чем операторы языков программирования. Поэтому, делаем ли мы это с помощью библиотек классов или библиотек процедур, нам придется столкнуться с резким увеличением размеров наших словарей программирования. Изучение словаря составляет значительную часть препятствий к повторному использованию.
      На сегодняшний день есть библиотеки классов, насчитывающие свыше 3000 членов. Многие объекты требуют задания от 10 до 20 параметров и переменных-переключателей. Всякий, использующий такую библиотеку, должен изучить синтаксис (внешние интерфейсы) и семантику (подробное поведение функции) ее членов, если собирается полностью реализовать потенциал повторного использования.
      Эта задача вовсе не безнадежна. Обычно человек использует около 10000 слов родного языка, образованные люди — значительно больше. Каким-то образом мы обучаемся синтаксису и тонким семантическим различиям. Мы правильно опеределяем различия между словами гигантский, огромный, пространный, колоссальный, громадный — никто не говорит о колоссальных пустынях и пространных слонах.
      Нужны дополнительные исследования, чтобы можно было применить к проблеме повторного использования программ существующие знания о том, как люди овладевают языком. Некоторые выводы непосредственно очевидны:
      • Обучение происходит в контексте предложения, поэтому нужно публиковать многочисленные примеры составных продуктов, а не просто библиотеки составляющих частей.
      • Человек запоминает только правописание. Синтаксис и семантика изучаются постепенно, в контексте, путем применения.
      • Человек группирует правила соединения слов в синтаксические классы, а не в совместимые подмножества объектов.
       Чистый итог по пулям: положение прежнее
      Итак, мы возвращаемся к основам. Сложность — это то, чем мы занимаемся, и сложность — это то, что нас ограничивает. Р. Л. Гласс (R. L. Glass) писал в 1988 году, точно суммируя мои взгляды 1995 года:
      Так что же в итоге сообщили нам Парнас и Брукс? Что разработка программ является концептуально сложным занятием. Что волшебные решения не лежат за каждым углом. Что занимающимся этим делом пора изучить достижения, имеющие эволюционный характер, а не ждать революцию и не надеяться на нее.
      Некоторые считают это безрадостной картиной. Это те, кто полагал, что вот-вот наступит прорыв.
      Но некоторые из нас — достаточно сварливые, чтобы считать себя реалистами, — относятся к этому как к глотку свежего воздуха. Наконец-то можно сосредоточиться на чем-то более близком к жизни, чем журавль в небе. Теперь, вероятно, мы сможем заняться постепенными усовершенствованиями производства программного обеспечения, которые действительно достижимы, а не ждать прорывов, которые вряд ли когда-либо произойдут. [29]

      Сегодня о технике разработки программного обеспечения известно значительно больше, чем в 1975 году. Какие из утверждений, содержащихся в первом издании 1975 года, подтвердились опытом и данными? Какие были опровергнуты? Какие устарели в нашем изменчивом мире? Чтобы вам легче было судить, здесь, в виде сводки, приведены важнейшие утверждения книги 1975 года, которые я считал верными: факты и извлеченные из опыта практические правила, приведенные с сохранением изначального смысла. (Можно задаться вопросом: если это все, что было сказано в первоначальном издании, почему тогда это заняло так много места?) В скобках приведены свежие комментарии.
      Большинство этих предложений можно проверить на практике. Излагая их в сжатой форме, я надеюсь сконцентрировать мысли читателя, измерения и комментарии.
       Глава 1. Смоляная яма
      1.1 Для создания системного программного продукта требуется примерно в девять раз больше усилий по сравнению с составляющими его программами, написанными отдельно для частного использования. По моей оценке, превращение программы в продукт вводит коэффициент, равный трем; проектирование, интеграция и тестирование компонентов, которые должны образовать согласованную систему, также вводит коэффициент, равный трем; все эти составляющие стоимости существенно независимы друг от друга.
      1.2 Занятие программированием «отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех у нас», доставляя пять видов радости:
      • Радость, получаемая при создании чего-либо своими руками.
      • Удовольствие создавать вещи, которые могут быть полезны другим людям.
      • Очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей.
      • Радость, получаемая от неизменного узнавания нового, неповторяемости задачи.
      • Удовольствие от работы со столь податливым материалом — чистой мыслью, который, тем не менее, существует, движется и работает так, как не могут словесные объекты.
      1.3 В то же время этому занятию присущи и огорчения:
      • При изучении программирования труднее всего привыкнуть к требованию совершенства.
      • Постановка задач осуществляется другими людьми и приходится зависеть от вещей (особенно, программ), которые нельзя контролировать; полномочия не соответствуют ответственности.
      • Страшно только на словах: фактическая власть приобретается как следствие успешного выполнения задач.
      • Программный проект приближается к окончательному виду тем медленнее, чем ближе окончание, хотя кажется, что к концу сходимость должна быть более быстрой.
      • Программному продукту грозит устаревание еще до его завершения. Настоящий тигр — не пара бумажному, если требуется реальное использование.
       Глава 2. Мифический человеко-месяц
      2.1 Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам, вместе взятым.
      2.2 Чтобы приготовить вкусную пищу, нужно время; некоторые задачи нельзя ускорить, не испортив результат.
      2.3 Все программисты являются оптимистами: «Все будет хорошо».
      2.4 Поскольку программист работает с чистыми идеями, мы не ожидаем особых трудностей при реализации.
      2.5 Но сами наши идеи бывают ошибочными — отсюда и ошибки в программах.
      2.6 Наши методы оценивания, основанные на учете затрат, смешивают затраты с полученным результатом. Человеко-месяц является ошибочным и опасным заблуждением, поскольку предполагает, что месяцы и количество людей можно менять местами.
      2.7 Разделение задачи между несколькими людьми вызывает дополнительные затраты на обучение и обмен информацией.
      2.8 Мое практическое правило: 1/3 времени — на проектирование, 1/6 — на написание программы, 1/4 — на тестирование компонентов и 1/4 — на системное тестирование.
      2.9 Как научной дисциплине нам не хватает методов оценки.
      2.10 Поскольку мы не уверены в своих оценках сроков работы, нам часто не достает смелости упрямо отстаивать их под нажимом руководства и клиентов.
      2.11 Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
      2.12 Добавление рабочей силы увеличивает общий объем затрат тремя путями: труд по перекраиванию задач и происходящее при этом нарушение работы, обучение новых людей, дополнительное общение.
       Глава 3. Операционная бригада
      3.1 Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых при равной подготовке и двухлетнем стаже (Сакман, Грант и Эриксон).
      3.2 Данные Сакмана, Гранта и Эриксона не выявили корреляции между опытом и продуктивностью. Я думаю, что это всегда так.
      3.3 Лучше всего иметь маленькую активную команду — как можно меньше мыслителей.
      3.4 Часто лучше всего, если команда состоит из двух человек, один из которых является лидером. (Обратите внимание, как Богом задуман брак.)
      3.5 Для создания действительно крупных систем маленькая активная команда работает слишком медленно.
      3.6 Опыт разработки большинства действительно больших систем показывает, что подход к ускорению с позиций грубой силы оказывается дорогостоящим, медленным, неэффективным и приводит к появлению систем, не являющихся концептуально целостными.
      3.7 Организация по типу хирургических бригад с главным программистом предлагает способ достижения целостности продукта благодаря его проектированию в нескольких головах и общей продуктивности благодаря наличию многочисленных помощников при радикально сокращенном обмене информацией.
       Глава 4. Аристократия, демократия и системное проектирование
      4.1 «Концептуальная целостность является наиболее важным соображением при проектировании систем.»
      4.2 «Окончательную оценку проекту системы дает отношение функциональности к сложности концепций», а не только богатство функций. (Это соотношение является мерой простоты использования, пригодной как для простого, так и для сложного использования.)