Делу время, потехе час! Тезисы «мифического человеко-месяца» Фредерика Брукса, в пословицах и поговорках

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

Была сформирована группа из 25 человек, которая занялась разработкой плана.

Весь аппаратно-программный комплекс назвали System/360, а операционную систему — OS/360. Иронично, что проблемы обратной совместимости были решены за счёт отказа от совместимости с предыдущими системами.

Почему программирование приносит радость? Какие удовольствия в качестве награды ждут его практика? Это радость от постоянного усвоения нового — этого предостаточно в неповторяющейся работе. Так или иначе, проблема всегда нова, и решающий её чему-то учится: иногда практическому, иногда теоретическому, а иногда и тому и другому.

Необходимость постоянно изучать новое, Брукс считает особой радостью программирования. Возможно с годами, оно будет уже не в радость, а в тягость, но сейчас я с ним соглашусь, ведь ученье — свет.

Человек должен действовать безупречно. Компьютер похож на магию и в этом отношении тоже. Если один символ, одна пауза заклинания не находится строго в правильной форме, то волшебство не сработает. Необходимость приспосабливаться к требованиям совершенства — это, я думаю, самая трудная часть овладения программированием.

Выбор пословицы должен приободрить читателя, ведь какими бы ни были трудности — человек с ними справится.

Конечные целевые критерии устанавливают другие люди, они предоставляют ресурсы и обеспечивают информацией. Редко кто-то контролирует условия своей работы или даже её цель. С точки зрения менеджмента, мы зависим от многих.

Зависимость от других имеет особенно неприятную системному программисту сторону.

Заниматься дизайном великих концепций — это удовольствие; отыскивать мелкие ошибки — это просто работа на поиск последних ошибок приходится тратить больше времени, чем на поиск первых.

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

Все программисты — оптимисты. Возможно, это современное колдовство в особенности привлекает тех, кто верит в счастливый конец и сказочных волшебниц. Возможно, сотни мелких разочарований отпугивают всех, кроме зацикленных по привычке на конечной цели.

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

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

Однако большие проекты в разработке состоят из многих задач, и вероятность того, что всё пойдёт хорошо, становится ничтожно малой.

Во многих творческих видах деятельности среда исполнения является неподатливой. Древесина раскалывается, краски размазываются, электрические цепи закольцовываются.

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

Хотел написать что не ошибается тот, кто ничего не делает. Но это было бы похоже на попытку оправдаться. Брукс же не ставит это нам в укор, поэтому оправдания и не нужны. А нужно просто помнить, что людям свойственны ошибки и планировать работу учитывая риски, конь, вот, о четырёх ногах, а тоже спотыкается.

Наши методики оценивания ошибочно путают усилия с прогрессом, допуская, что люди и месяцы взаимозаменяемы. Стоимость действительно варьируется в зависимости от числа людей и числа месяцев. Ход выполнения — нет.

Люди и месяцы являются взаимозаменяемыми только тогда, когда работа может быть распределена между многими работниками без коммуникаций между ними.

Многие проекты укладывались в график на всех этапах, исключая тестирование.

Поскольку сбой происходит в конце графика, никто не подозревает о проблемах вплоть до даты поставки. Более того, задержка в этом месте имеет необычайно серьёзные финансовые и психологические последствия. Поэтому в исходном графике работ очень важно предусмотреть достаточное время на тестирование системы.

Следует сделать оговорку что речь про “каскад”, т.е. тестирование идёт в конце или ближе к нему. Однако каким бы модным и молодёжным agile вы не пользовались, постарайтесь хотя бы о “камень” не спотыкаться. Уделять время на тестирование в достаточном количестве следует независимо от выбранной методологии.

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

Для программиста, как и для шеф-повара, нетерпеливость со стороны заказчика может привести к изменению запланированного срока завершения задачи. Впрочем, повар может предложить ещё вариант — добавить огня. В результате часто омлет уже ничем не спасёшь: подгорит с одной стороны и будет сырым с другой.

Оно же “поспешишь — людей насмешишь” и “наскоро делать — переделывать”, но вариант со словом “терпенье” к проблеме нетерпеливости подходит лучше.

Ещё мне нравится аналогия с шеф-поваром.

Когда выявляется отставание от графика, естественным (и традиционным) ответом становится добавление рабочей силы. Это всё равно что подлить масла в огонь: будет только хуже, гораздо хуже.

Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.

Максимальное число человек зависит от числа независимых задач.

В одном из исследований измеряли производительность труда в группе опытных программистов. Соотношение между лучшими и худшими результатами составляло в среднем около 10:1 по производительности и, 5:1 по скорости и требуемой памяти программы! Данные не показали абсолютно никакой корреляции между опытом и производительностью.

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

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

Эта моя любимая, ибо не в бровь, а в глаз. Конечно Брукс вкладывает немного другой смысл, чем тот, что подразумевается в пословице, но численность совпала идеально, т.к. в “хирургической бригаде Миллса” подразумевается 9-10 человек, из них всю разработку ведут два человека (хирург и второй пилот), +7 на подхвате, +1 (языковой консультант) который может состоять в нескольких “бригадах”, и в пословице 2+7… Совпадение? Не думаю!

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

ХИРУРГ. Миллс называет его главным программистом. Он лично задаёт спецификации по функциональности и производительности, разрабатывает дизайн программы, кодирует её, тестирует и пишет документацию. Он имеет большой талант, десятилетний опыт и значительные системные и прикладные знания, будь то прикладная математика, обработка бизнес-данных или что-то ещё.

ВТОРОЙ ПИЛОТ. Он является альтер эго хирурга, способен выполнить любую часть работы. Его главная задача — участвовать в проектировании, где он должен думать, обсуждать, оценивать. Он досконально знает весь код. Он исследует альтернативные стратегии дизайна. Очевидно, он служит для хирурга страховкой от катастрофы.

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

АДМИНИСТРАТОР. Управляет деньгами, людьми, пространством и машинами и взаимодействует с административным аппаратом остальной организации.

РЕДАКТОР. Хирург отвечает за генерирование документации. Редактор, берёт черновик или продиктованную рукопись, подготовленную хирургом, и подвергает её критическому анализу, перерабатывает, снабжает ссылками и библиографией, пропускает её через несколько версий и контролирует механику производства.

ДВА СЕКРЕТАРЯ. Администратору и редактору, каждому в отдельности, понадобится секретарь.

ДЕЛОПРОИЗВОДИТЕЛЬ. Он отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта.

ИНСТРУМЕНТАЛЬЩИК. Ответственный за обеспечение доступа к основным службам, а также за создание, поддержку и обновление специальных инструментов.

ЯЗЫКОВОЙ КОНСУЛЬТАНТ. Их талант несколько отличается от таланта хирурга, который в первую очередь является системным дизайнером и мыслит представлениями. Языковой консультант может находить безупречный и эффективный способ использовать язык для того, чтобы делать трудные, смутные или каверзные вещи. Часто ему приходится проводить небольшие исследования (в течение двух-трёх дней) по отысканию хорошего технического решения.

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

Несмотря на то что для сборки большинства систем программирования не требовались столетия, они демонстрируют гораздо худшую концептуальную разобщенность, чем соборы. Обычно это происходит не из-за смены проектировщиков, а из-за разделения проекта на многочисленные задачи, выполняемые многими людьми.

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

Отделение архитектурных усилий от имплементации является мощным способом получения концептуальной целостности в крупных проектах.

Если система должна обладать концептуальной целостностью, то руководство концепциями должен взять кто-то один.

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

Первая работа архитектора, как правило, является щадящей и чистой. Он знает, что не знает что делает, поэтому делает это осторожно и очень сдержанно.

По мере работы над дизайном первой системы, ему на ум приходят украшение за украшением, фишка за фишкой. Они будут сохранены для использования «в следующий раз». Эта вторая система — самая опасная для человека, который её проектирует. Общая тенденция — делать дизайн второй системы с большим запасом, используя все идеи и излишества, которые были осторожно отклонены в первой.

Как менеджеру проекта избегать эффекта второй системы? Настаивать на том, чтобы старший архитектор имел опыт разработки хотя бы двух систем.

Это получился скорее совет менеджеру, чем описание сути проблемы.

Как архитектор избегает эффекта второй системы? Совершенно очевидно, что он не может пропустить свою вторую систему. Но он может осознавать, какие особые опасности его подстерегают, и проявлять дополнительную самодисциплину.

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

Единство «Принципов работы» системы System/360 проистекает из того, что принадлежит перу только двух человек. Идеи принадлежат примерно 10 людям, но воплощение этих решений в текстовые спецификации должно быть проделано только одним человеком или двумя, если нужно сохранить единообразие и согласованность описания и продукта. Ибо написание определения потребует целого ряда мини-решений, которые не имеют дискуссионной важности.

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

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

Здесь, в выборе поговорки, прослеживается моя личная неприязнь к совещаниям, у Брукса как раз всё наоборот, там он совещания боготворит. Может он и прав, а мне надо пересмотреть своё отношение, в любом случае осознание проблемы — половина пути к исправлению.

Лучший друг менеджера проекта — его ежедневный противник, независимая организация по тестированию продукта.

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

Отдел тестирования здесь это то самое малое опасение, которое спасёт от пользовательского гнева. Ну или хотя бы попытается.

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

Катастрофа с графиком, функциональная несогласованность и системные ошибки возникают потому, что левая рука не знает, что делает правая.

Да, здесь я просто скопировал текст, дословно повторив идиому. Ну а что, тварь я дрожащая или право имею?!

Как же тогда команды должны обмениваться информацией друг с другом? Всеми возможными способами: неофициально, совещания, рабочая книга.

Рабочая книга проекта — это не столько отдельный документ, сколько структура, налагаемая на документы, которые проект так или иначе будет производить.

Все документы проекта должны быть частью этой структуры.

Технологический документ практически вечен.

Древовидная структура организаций отражает меньшую потребность в детальной коммуникации. Фактически древовидная организация возникает как структура полномочий и ответственности.

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

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

Данные, относимые к разработке изолированных малых программ, неприменимы к продуктам систем программирования. Линейно экстраполировать показатели забега в спринте бессмысленно. Объём работы растёт как степенная функция размера.

Продуктивность программирования может быть увеличена в 5 раз при использовании подходящего языка высокого уровня.

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

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

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

Каковы критически важные документы? Целевые критерии, спецификации, график работ, бюджет, организационная схема, распределение пространства, оценка, прогноз, цены.

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

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

Наконец, документы предоставляют менеджеру базу данных и контрольный список.

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

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

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

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

Тем не менее некоторые изменения в целевых критериях неизбежны, и лучше быть к ним готовым, чем уповать на то, что они не наступят.

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

С течением времени система становится всё менее упорядоченной. Рано или поздно исправление ошибок перестаёт приносить плоды. Каждый шаг вперёд сопровождается шагом назад.

Таким образом, думайте сами, решайте сами, менять или не менять, но Брукс предупреждает, а предупреждён — значит вооружён.

Даже в наш высокотехнологичный век многие программные проекты по-прежнему работают как токарные мастерские, когда речь идёт об инструментах. Каждый мастер тщательно охраняет свой личный набор, собранный за всю жизнь, — видимые свидетельства личных навыков. Точно так же программист хранит маленькие редакторы, сортировщики, двоичные дампы, дисковые утилиты и т. д., припрятанные в его папке.

Интересно, а без чего не программист?

Существенной проблемой является коммуникация, а индивидуализированные инструменты скорее препятствуют, чем помогают коммуникации.

То, что коммуникации главная проблема, постулировалось ещё в главе “почему провалился вавилонский проект”, а раз это главная проблемы, именно она и будет тяготеть и нарастать по любой возможной причине и без причины.

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

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

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

Тщательное определение функций, тщательная спецификация и дисциплинированное изгнание излишеств функциональности и полётов технической мысли — всё это уменьшает число системных ошибок, которые должны быть найдены.

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

Задействовать отлаженные компоненты. Здравый смысл, если не обычная практика, говорит нам, что отладку системы следует начинать только после того, как её части, работают. Использование чистых, отлаженных компонентов экономит гораздо больше времени при тестировании системы

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

Добавлять по одному компоненту за раз. Эта заповедь тоже очевидна, но оптимизм и лень вынуждают нас её нарушать. И в конце концов, не окажется ли, что вся эта работа не понадобится? Может быть, нет никаких ошибок?

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

Катастрофа обычно происходит из-за термитов, а не из-за торнадо; отставание происходило незаметно, но неумолимо.

Снегопад, работа в суде присяжных, семейные проблемы, экстренные встречи с клиентами, проверки начальства — список можно продолжать и продолжать. Каждое из этих событий задерживает работу лишь на полдня или на день. И растёт отставание от графика, каждый раз ещё на один день.

Как контролировать крупный проект по жесткому графику? Первый шаг — иметь график. Каждое событие из списка событий, именуемых контрольными точками, имеет дату.

Для подбора контрольных точек есть только одно релевантное правило. Контрольные точки должны быть конкретными, специфичными, измеримыми событиями, точно определёнными.

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

Пока менеджер думает, что он может решить проблему в одиночку, он не говорит боссу.

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

В течение нескольких лет я читал лекции по инженерии программного обеспечения о необходимости и уместности хорошей документации, убеждая студентов все горячее и красноречивее. И это не работало. Я предположил, что они поняли, как правильно составлять документацию, но не делали этого по недостатку рвения. Тогда я попытался показать им, как делается работа. Это оказалось гораздо успешнее.

Это относится не столько к самой документации, о её необходимости мы уже начитались, я сыт по горло, это относится к тому, как привить людям правильное отношение к документации — на собственном примере. конечно же.

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

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

Программные объекты постоянно подвержены изменениям. Отчасти это связано с тем, что программное обеспечение в системе воплощает её функциональность, а функциональность является той частью, которая больше всего чувствительна к изменениям. Как правило, программное обеспечение легче изменить — это чистый мысленный материал, бесконечно податливый.

Насколько больше пользы можно ожидать от прорывных исследований в области оптимальных сред программирования? Специфичные для языка умные редакторы являются новшеством, которое ещё не нашло широкого применения на практике, но самое большее, что они обещают, — это свобода от синтаксических и простых семантических ошибок.

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

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

Разница между слабыми концептуальными дизайнами и хорошими может лежать в здравости метода разработки, разница между хорошими дизайнами и великими, конечно, не в этом. Великие дизайны приходят от великих разработчиков. Создание программного обеспечения является творческим процессом. Здравая методика может наделить силой и освободить творческий ум; однако она не может воспламенить или вдохновить работягу.

Полемику о том. что считать “сильным”, а что “великим” наверно опустим — всё познаётся в сравнении.

В статье говорится прямо: «Когда мы смотрим на горизонт десятилетия, мы не видим никакой серебряной пули… Однако скептицизм не есть пессимизм… Королевской дороги нет, но есть дорога». Она предсказывает что инновации, которые находятся на этапе своего развития в 1986-м, если будут разработаны и использованы, все совместно приведут к увеличению продуктивности на порядок.

Наличие дешёвого, мощного коммерческого программного обеспечения удовлетворило многие потребности, которые ранее служили бы поводом для заказных пакетов.

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

Это критика к тезису, что нужно стремиться покупать готовые программные пакеты, а не заказывать разработку с нуля. И, как мы видим, заказная разработка всё ещё жива, и живее всех живых, а значит Селин был прав. Всегда находится какая-то хотелка, которая отсутствует в готовом пакете, либо пакет настолько обобщённый, что настройка под себя, немногим отличается от заказной разработки.

Если мы проектируем крупные классы, представляющие концепции, с которыми наши клиенты уже работают, то они в состоянии понимать и критиковать проект по мере его развития, а также вместе с нами разрабатывать контрольные примеры. Офтальмологов, с которыми я работаю, не волнует организация стека; их волнует описание формы роговицы с помощью полиномов Лежандра. Маленькая инкапсуляция даёт и маленькую выгоду.

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

Ранее в книге утверждалось, что использование высокоуровневых языков программирования было прорывом в скорости разработки ПО, а вот это уже обратная сторона медали. Писать ПО стали быстрее, но дольше стали этому учиться.

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

Схожим образом данному ремеслу присущи особые горести.

Из-за нехватки календарного времени провалилось программных проектов больше, чем по всем другим причинам, вместе взятым.

Добавление людей в проект по созданию программного обеспечения требует увеличения суммарного усилия по трём направлениям: [необходимость] перераспределения работы и вызванное этим нарушение хода текущих работ, [необходимость] обучения новых людей, и увеличение [накладных] расходов на коммуникацию [в большем коллективе].

Как архитектор может успешно влиять на имплементацию:

Помнить, что творческую ответственность за имплементацию несёт строитель; архитектор только предлагает идеи.

Быть готовым предложить способ имплементации всего, что он [архитектор] предлагает; быть готовым принять любой другой столь же хороший способ.

Вторая система является самой опасной для человека, который её проектирует; общая тенденция — делать дизайн с большим запасом.

Непреодолимое искушение для архитектора, состоит в перегрузке продукта функциями незначительной полезности за счёт производительности и даже простоты использования.

Как фактическая потребность, так и восприятие этой потребности пользователем будут меняться по мере разработки, тестирования и использования программ.

Да, у пользователей семь пятниц на неделе, да и не только у них.

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

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

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

Поэтому в той мере, в какой «Мифический человеко-месяц» написан о людях и командах, он устаревает медленно.

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

Границы подсистем легче всего строго определить в тех местах, где интерфейсы между подсистемами минимальны. Тогда каждая часть будет иметь своего собственного архитектора, который должен отчитываться перед главным архитектором системы в отношении архитектуры.

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

Конечно пользователи не начальство, если буквально, но с учётом того, что конечный продукт разрабатывается именно для них, я считают такую подмену допустимой.

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

Теперь, функция за функцией, мы инкрементно создаём и добавляем модули. На каждом этапе у нас есть работающая система.

А ведь эта поговорка — плоть от плоти инкрементной разработки, как я раньше не замечал?!

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

Схожим образом разработчики вполне могут взяться за построение вертикального среза продукта, в котором в полной мере выстроен лимитированный набор функций. Возможно, это поможет раньше пролить свет на те места, где могут скрываться змеи снижения производительности.

В проекте OS/360 мы решили, что все программисты должны видеть весь материал, то есть каждый программист должен иметь копию рабочей книги проекта, которая насчитывает более 10 000 страниц. Эта точка зрения резко контрастирует с учением Дэвида Парнаса о том, что модули кода должны быть инкапсулированы с чётко определёнными интерфейсами и что внутренняя часть такого модуля должна быть частной собственностью его программиста, невидимой извне. Парнас был прав, а я ошибался. Теперь я убежден, что сокрытие информации, которое сегодня часто воплощается в объектно-ориентированном программировании, является единственным способом повышения уровня дизайна программного обеспечения.

Модель COCOMO Бема находит, что качество команды является самым важным фактором её успеха, действительно в 4 раза более мощным, чем следующий по величине фактор.

Крупным достижением последних лет стала книга Демарко и Листера «Кадровое обеспечение: продуктивные проекты и команды». Она изобилует драгоценными камнями, такими как: «Функция менеджера заключается не в том, чтобы заставить людей работать, а в том, чтобы дать им возможность работать».

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

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

Интеллектуальная дисциплина, связанная с компьютером, получила взрывное развитие, как и технология. Когда я был аспирантом в середине 1950-х годов, я мог читать все журналы и материалы конференций; я мог оставаться в курсе всего в индустрии. В моей сегодняшней интеллектуальной жизни можно наблюдать, как я с сожалением прощаюсь с субдисциплинарными интересами, один за другим, поскольку мое портфолио постоянно заполняется, выливаясь за пределы возможностей. Слишком много интересов, слишком много захватывающих возможностей для усвоения, исследований и размышлений. Какое изумительное недоразумение! Мало того что конца этому не видно, так еще и темп не замедляется. У нас много будущих радостей.