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

Время — судья

Книга “мифический человеко-месяц”, заслуживает того, чтобы её читали и перечитывали, издавали и переиздавали. В 2025 году, а он не за горами, будет 50 лет первому изданию. Т.е. проверка временем пройдена. В 1995 году вышло юбилейное издание (ждём юбилейного издания 2К25), в предисловии к которому, автор, помимо прочего, сообщает:

Работая над обзором и обновлением книги «Мифический человеко-месяц», я поразился, как мало тезисы, заявленные в ней, были подвергнуты критике, доказаны или опровергнуты текущими исследованиями и опытом в инженерии ПО. Теперь для меня оказалось полезным каталогизировать эти тезисы в сырой форме, лишённой подтверждающих аргументов и данных. В надежде, что эти голые утверждения привлекут аргументы и факты для доказательства, опровержения, обновления или уточнения, я включил этот план в главу 18.

Кто празднику рад, тот накануне пьян

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

В споре рождается истина

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

А заодно расслабиться, и повеселиться. Не воспринимайте написанное слишком буквально — без смешного нельзя понять серьёзное.

Порядок дела не портит

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

❖ — Оглавление:

<sup>❒ Вступление

❒ «Хватит долго запрягать...» — основная часть</sup>

• ^{Предисловие научного редактора к русскому изданию 2020 года}
• ^{Глава 1. Смоляные ямы}
• ^{Глава 2. Мифический человеко-месяц}
• ^{Глава 3. Хирургическая бригада}
• ^{Глава 4. Аристократия, демократия и системный дизайн}
• ^{Глава 5. Эффект второй системы}
• ^{Глава 6. Доведение до сведения}
• ^{Глава 7. Почему провалился вавилонский проект?}
• ^{Глава 8. Попытки измерить}
• ^{Глава 9. Непосильный груз}
• ^{Глава 10. Документарная гипотеза}
• ^{Глава 11. Планируй выбросить}
• ^{Глава 12. Заточенные инструменты}
• ^{Глава 13. Целое и части}
• ^{Глава 14. И грянул гром}
• ^{Глава 15. Другая сторона}
• ^{Глава 16. Серебряной пули нет}
• ^{Глава 17. Повторный выстрел «Серебряной пули нет»пление}
• ^{Глава 18. Тезисы мифического человеко-месяца: false или true?}
• ^{Глава 19. Мифический человеко-месяц двадцать лет спустя}
• ^{Эпилог. Пятьдесят лет удивления, воодушевления и радости}

^{❒ «Пора и честь знать» — заключение}

Чем богаты, тем и рады

На всеобъемлющий охват, изложенных Бруксом мыслей, не претендую: из текста будут вырваны куски и проиллюстрированы какой-то пословицей, возможно что-то важное будет незаслуженно упущено. В общем, каждой сестре по серьге не обещаю.

Толкования поговорок и псевдо- “настоящих продолжений”/”полных версий”, здесь не будет — упаси боже.

Хватит долго запрягать, — поехали

Предисловие научного редактора к русскому изданию 2020 года

Баба с возу - кобыле легче

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

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

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

▍Глава 1. Смоляные ямы

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

Век живи - век учись

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

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

Не Боги горшки обжигают

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

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

Плясать под чужую дудку

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

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

Мал клоп, да вонюч

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

Ничто не вечно под луной

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

▍Глава 2. Мифический человеко-месяц

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

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

Волков бояться - в лес не ходить

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

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

Поезжай на неделю, а хлеба бери на две

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

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

И на старуху бывает проруха

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

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

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

Меряла бабка клюкой, да махнула рукой

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

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

Нашла коса на камень

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

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

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

На хотенье - есть терпенье

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

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

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

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

Хотели как лучше, а получилось как всегда

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

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

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

▍Глава 3. Хирургическая бригада

Глава о том, как сформировать команду так, чтобы дело спорилось.

ИМХО, но надо брать пример с армейцев в этом вопросе. Аналогия с армейским отделением будет выглядеть менее притянутой за уши:

• численность подобна
• как нигде более, все должны чётко знать свои обязанности,
• с учётом повышенного риска bus factor, ещё и уметь заменять друг друга

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

Не спрашивай старого, спрашивай бывалого

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

Двое пашут, а семеро руками машут

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

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

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

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

И швец, и жнец, и на дуде игрец

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

Одна голова хорошо, а две лучше

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

На одном гвозде всего не повесишь

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

Мастер один, а подносчиков десять

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

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

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

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

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

Не нужен учёный, а нужен смышлёный

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

Два медведя в одной берлоге не живут

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

▍Глава 4. Аристократия, демократия и системный дизайн

Всяк портной на свой покрой

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

Кто в лес, кто по дрова

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

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

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

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

▍Глава 5. Эффект второй системы

Главу открывает цитата Овидия: добавляй малое к малому, и ты получишь большую кучу.

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

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

Ну а проблема — это ретивые архитекторы которые хотят применить то, чему научились.

За битого двух небитых дают

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

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

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

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

И крута гора, да миновать нельзя

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

Опыт - сын ошибок трудных

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

▍Глава 6. Доведение до сведения

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

У семи нянек дитя без глазу

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

Много говорено, да мало сказано

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

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

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

От малого опасенья великое спасенье

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

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

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

Кто ищет - тот всегда найдёт

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

▍Глава 7. Почему провалился вавилонский проект?

Что-то ещё добавить — избыточно.

Левая рука не знает, что делает правая

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

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

Гора с горой не сходится, а человек с человеком сойдётся

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

Что написано пером, того не вырубишь топором

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

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

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

Не место красит человека, а человек место

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

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

▍Глава 8. Попытки измерить

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

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

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

Цыплят по осени считают

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

Чем дальше в лес, тем больше дров

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

На острую косу много покосу

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

▍Глава 9. Непосильный груз

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

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

Хотя… появление виртуальных серверов, доступных для аренды, к некоторым смысле возвращает нас к описанной Бруксом проблеме: выбранный нами тариф ограничит нас как по объёму оперативной памяти, так и по объёму диска. Да килобайтики считать уже не надо, теперь достаточно уложиться в 5 Гб. Ну а если не получилось в 5, тогда арендуй 10.

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

Цены тоже стали другими, разница между 5 и 10 Гб незначительна, особенно для крупного бизнеса. Но копейка рубль бережёт, поэтому к главе стоит, как минимум присмотреться.

Не постой за волосок — бороды не станет

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

Голь на выдумки хитра

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

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

▍Глава 10. Документарная гипотеза

Документируй всё. Документируй как мы, документируй вместе с нами, документируй лучше нас!..

Бумага всё стерпит

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

Пиши, записывай, набело переписывай!

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

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

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

▍Глава 11. Планируй выбросить

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

Хотя я каскад и не применяю, но всё же мне кажется что в моих системах проще кое-что выкинуть и написать заново, чем пытаться исправить на живую нитку.

Первый блин - комом

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

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

Отделить зёрна от плевел

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

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

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

Как снежный ком

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

Из собаки всех блох не выбьешь

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

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

▍Глава 12. Заточенные инструменты

Если зрить в корень, то глава про то что много сложных (и не очень), инструментов создано программистами, и для программистов, и для тех кто участвует в разработке на всех этапах. И этими инструментами являются и IDE, и сами языки, и средства проектирования, и средства документирования, и отладки, и тестирования, и чего там только нет, — глаза разбегаются.

А теперь всем этим надо учиться пользоваться — часть ремесла, и вообще полезно для дела.

Без топора не плотник, без иглы не портной

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

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

Где тонко, там и рвётся

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

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

Топор острее, так и дело спорее

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

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

▍Глава 13. Целое и части

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

На словах ты Лев Толстой...

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

Семь раз отмерь, один раз отрежь

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

Доверяй, но проверяй

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

Паршивая овца всё стадо портит

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

Кабы знал, где упасть, так бы соломки подостлал

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

Тише едешь - дальше будешь

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

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

▍Глава 14. И грянул гром

Название главы просто провоцирует сказать: “гром не грянет, мужик не перекрестится”. К чему это? Неважно! А глава о том как происходит отставание от графика.

По капельке море, по зёрнышку ворох

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

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

Не уговорясь на берегу, не пускайся за реку!

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

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

Не ведает царь, что делает псарь

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

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

С самого начала, у меня была какая-то тактика, и я ей следовал

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

▍Глава 15. Другая сторона

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

Что крестьяне - то и обезьяне

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

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

▍Глава 16. Серебряной пули нет

В представлении не нуждается.

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

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

Терпение и труд всё перетрут

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

Вода камень точит

Сначала хотел написать правило: ешь слона по частям. Но так непреодолимо жалко слона стало.

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

Кто везёт - на том и едут

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

Не куёт железа молот, куёт кузнец

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

От работы кони дохнут

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

Плохое начало - и дело стало

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

Нетрудно сделать, да трудно задумать

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

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

▍Глава 17. Повторный выстрел «Серебряной пули нет»

Ответ Брукса на замечания в его статье “серебряной пути нет”.

Не так страшен чёрт, как его малюют

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

Горбатый на базаре шубы не покупает

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

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

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

С волками жить - по-волчьи выть

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

Легче руками работать, чем головой

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

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

▍Глава 18. Тезисы мифического человеко-месяца: false или true?

Цель моей публикации и цель этой главы совпадает, и, казалось, можно было бы эту главу пропустить и не делать тезы о тезисах. Но нет. Ведь порой за деревьями не видно леса, и потому эта глава важна, она позволяет сделать шаг назад и посмотреть ещё раз на материал, но уже с другого расстояния. А большое видится издалека. Что-то из этого может вполне подтолкнуть к свежим мыслям.

Рыбы без костей не бывает

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

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

Кто не успел, тот опоздал

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

На огонь дров не напасёшься

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

Дай, Боже, всё самому уметь, да не всё самому делать

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

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

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

Лучшее - враг хорошего

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

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

Задним умом крепок

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

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

Новую одежду кроят, к старой примеряют

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

Шила в мешке не утаишь

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

▍Глава 19. Мифический человеко-месяц двадцать лет спустя

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

Всё новое - хорошо забытое старое

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

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

Одна пчела немного меду натаскает

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

Первый в совете - первый в ответе

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

Начальство надо знать в лицо

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

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

Были бы кости, а мясо нарастёт

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

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

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

Берегись бед, пока их нет

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

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

Много будешь знать - плохо будешь спать

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

Кадры решают всё

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

Руководить — это значит не мешать хорошим людям работать

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

Каков поп - таков приход

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

Не мытьём так катаньем

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

▍Эпилог. Пятьдесят лет удивления, воодушевления и радости

Иное время - иное бремя

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

«Пора и честь знать» — заключение

По мере ума и фантазии, книгу разобрал, дополняйте в комментариях.

То, что для описания тезисов выбраны пословицы и поговорки, — неслучайно: они легко запоминаются и мы ими пользуемся каждый день — это отличный якорь. Да и сам Брукс каждую свою главу начинает с иллюстрации и крылатого выражения, — я старался держать марку.

Кадр из фильма «Брат» 1997 г., режиссёр Алексей Балабанов

Аппетит приходит во время еды

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

Приятного аппетита!