Наконец дочитал "Мифический человеко-месяц" Брукса. Последние пару месяцев это у меня была самолетная книга, вот, во вчерашнем перелете добил последнюю главу.

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

С одной стороны – это рассказ современника о повседневной работе системных программистов в 60-ых годах. Вдумайтесь, это книга была написана почти 50 лет назад, а речь в ней идет о разработке (операционной системы OS/360), которая велась почти 60 лет назад. Это самая настоящая древность, рассказ о потерянном мире, где фактически существовали только системные программисты, при том из инструментов у них были палка, да камень ассемблер, да PL/1.

—

На этом фоне технические рассуждения Брукса могут казаться немного наивными, что он сам подтверждает в последней главе, дописанной в 95 году (все еще почти 30 лет назад!), но от того только лучше подчеркивающие историческую ценность.

Приведу пару примеров:

1) Брукс много времени посвящает рассуждениям о том, что надо таки всем переходить на языки высокого уровня:

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

И при этом тут же добавляет:

Какой язык высокого уровня следует использовать для системного программирования? Единственным разумным кандидатом на сегодняшний день является PL/1.

Но если вспомнить о дате написания (1975 год), то становится понятно, что С просто еще недостаточно заматерел, чтобы его прям приняли в индустрии, так что это вполне себе артефакт эпохи.

2) Брукс много говорит про документацию (и это круто!), но при этом рассказывает, как все было устроено у них в проекте: у каждого инженера на столе была распечатана вся документация на OS/360, каждую ночь изменения в документации печатались и книги всех инженеров обновлялись (страницы вклеивались или заменялись). Мало того, что это требовало огромных усилий целого отдела сопровождающего документацию, так еще и через полгода разработки такая книжка стала полтора метра высотой. Тогда было принято решение перейти на микрофиши, что решило проблему, но лишило разработчиков возможности чиркать на полях :(

Даже сам Брукс говорит, что "сейчас (в 1975 году), наверное, можно было бы завести один файл, к которому все будут обращаться дистанционно, при том изменения хранить в виде LIFO". Т.е. он во многом предугадал будущее и появление систем контроля версий, хотя еще долгое время считал, что каждый инженер должен ежедневно читать обновление документации всего проекта (позже он и от этой идеи отказался).

3) Целая глава посвящена ограничениям ресурсов при работе программ, но при этом особый фокус делается на размер кода, много говорится о том, что сами программы обязаны быть компактными. В 2024 году это звучит очень необычно, ведь мало есть областей, где это действительно важно (ну, как, был у меня опыт борьбы за размер скомпилированного бинаря, включающего рантайм, был, .text секцию вполне поджимал).

—

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

—

Что же касается основной части книги, за которую ее все и ценят: менеджерские советы, как управлять большими программными проектами и программистами, здесь ситуация видится мне противоположной ↓

В менеджерской части все наоборот. Неважно, что книга написана 50 лет назад: проблемы то у проектов все те же (люди за 50 лет не эволюционировали, а проблемы в управлении – они же от людей, а не от машин).

Более того, не так важно, что речь идет именно о программировании, собрать воедино труд десятков и сотен работников интеллектуального труда – это общий челендж (Брукс все время сравнивает это с проектами химиков, пусть так).

Наконец, думаю, люди вот уже 50 лет постоянно повторяют описанные Бруксом советы, поэтому они кажутся довольно привычными. Он и сам про это хорошо сказал в своей последней главе "Мифический человеко-месяц двадцать лет спустя":

Незнакомец, сидевший рядом со мной читал "Мифический человеко-месяц", и я ждал, как он отреагирует – словом или знаком. Наконец, когда вырулили к выходу, я не выдержал:

- Как вам эта книга? Рекомендуете?
- Гм! Ничего такого, чего бы я уже не знал.

Я предпочел не представляться.

Тем не менее, перечислю пару зацепивших меня моментов:

1) Брукс говорит, что создание программного продукта в 9 раз дороже, чем написание программы для личного пользования. При том внедрение отдельного компонента дает коэффициент x3, а сборка всего продукта - еще x3.

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

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

3) Наверное, самый спорный для меня момент – сравнение архитекторов с аристократией (а простых работяг, видимо, с крестьянами). Дескать это высшая лига, на которой огромная ответственность за дизайн всей системы. Я согласен, что такое разделение труда имеет смысл, но метафора вызывает у меня явное отвращение.

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

4) Интересная мысль про эффект второй системы, что она обречена. Т.е. вот пишет (дизайнит) человек первый свой транслятор, что-то у него получается. Но когда он начнет дизайнить второй свой транслятор, он попытается исправить в нем все недостатки первого, реализовать там все свои идеи с прошлого проекта, которые туда не поместились. Это может привести к перегруженности и неэлегантности второй системы. Мысль очень интересная.

5) Ну и конечно: потрясающая глава про планирование и срывы дедлайнов. Там целый набор интересных наблюдений и советов: и то, что никто по собственной воле не рассказывает начальнику о появляющихся сложностях, а сначала пытаются решить это на местах (поэтому продолбы могут быть внезапными); и то, насколько четкими должны быть майлстоуны (или их точно продолбают); и то, что заниженные оценки обычно вскрываются именно за 3 недели до дедлайна.

—

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

Простым работягам типа меня я бы советовал книжку прочитать, чтобы использовать ее, как лакмусовую бумажку: если ваш начальник не знает про описанные здесь вещи; раз за разом совершает приведенные Бруксом ошибки; тушит пожары бензином добавлением рабочей силы, то может стоит задуматься: такой ли он хороший начальник? (если он ничего этого не делает, то все равно не факт, что все хорошо, признак необходимый, но не достаточный) ↓

Ну и пара технических замечаний:

1) Перевод, честно говоря, не очень. Я часто сверялся с оригиналом, т.к. мысль в русской версии прям терялась из-за корявости перевода. Может стоило читать полностью на англ, но вот именно себе я купил русскую бумажную версию, так что ой;

2) Смотрите сноски! Они как-то неудобно приведены в конце книги, но как же приятно там было встретить цитирование Ершова, например (еще один признак той эпохи);

3) Последние две главы с рефлексией спустя 20 лет и ответами на критику мне показались не особо интересными. Какие-то у него там совсем базовые размышления про ООП пошли, мне показалось, что слабовато.

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