Мифический человеко-месяц

или как создаются программные системы

Прочитал я знач «Мифический человеко-месяц» Брукса.

Думаю, лично мне стоило это сделать лет 8 назад. Однако лучше поздно, чем никогда.

Книга оставляет порой неоднозначные чувства, но мне зашло; и в первую очередь по следующим причинам:

• Это «классический» труд: книга вышла в 1975-м, а многие топики оттуда актуальны и по сей день. К сожалению, это также и причина, почему местами достаточно сложно продираться через терминологию. Чувак не отказывает себе в возможностях нырнуть в технические детали, которые в современном мире имеют мало практического смысла, тогда как общий посыл — напротив.
• Ещё мне нравится, как автор то и дело ссылается на людей поимённо. Типа: а вон тот типок придумал инкрементальный подход в 45-м, а вот этот — быстрое прототипирование в 50-м, а третий вот инкапсуляцию там ещё в хуй знает каком. Причём для нас эти люди сейчас легендарны, на их работах базируется всё современное IT, а Брукс пишет чуть ли не в духе: «ну, сидели мы с ними знач на кухне и спорили за вотерфолл…». Что, если не это, значит, что и сам Брукс — легенда? (Вопрос риторический, конечно 🙂).
  И ты такой читаешь: «Еееббать», — думаешь, — «не так давно это всё учил только, а оно уже существует в два раза дольше, чем я сам».
  
  В таких случаях у меня неизбежно возникают вопросы по типу: а знали ли все те люди тогда, что их работа станет фундаментом целой отрасли? И замечали ли это окружающие или же на тот момент они все просто решали насущные задачи?
  Хочется непременно применить это на текущие времена, потому что ныне складывается ощущение, будто прорывов-то никаких и не происходит. Ну, или не складывается, а скорее выражается в виде надежды, т.к. если фундамент нашего будущего — это реакты и кубернетисы, то нам пизда 😅
• Книга содержит в себе очень мало воды: исследования, рассуждения, споры и мысли, эмпирические формулы — всё это преимущественно снабжено ссылкой на первоисточник, что сразу добавляет +10 к доверию. При этом автор (чаще всего) не говорит: «Делай вот так-то и так-то, а вон то всё хуйня», — нет, он говорит честно: «Я уверен в своём мнении, но мы с мужиками поспорили, и хуй его знает, как правильно, но вот тут и тут наши мнения сходятся, а там уж сами решайте».
  Так или иначе, пару — тройку весьма прагматичных, готовых к применению штук я из книги подцепил.

Что не понравилось:

• Местами нудновато читается книга как раз из-за налёта старины. Пусть я достаточно неплохо знаком с историей отрасли, были главы, где я понимал примерно половину — приходилось параллельно штудировать википедию, чтобы окунуться в атмосферу разработки тех лет.
• Не критичный момент, но чел часто делает отсылки к Господу и прочим религиозным херням. В целом не имею ничего против, просто в технической книге немного мозолит глаз.
• Субъективный момент, который вызывает лично у меня некоторые негативные эмоции: Брукс достаточно убедительно объяснил, почему революции в сфере разработки программного обеспечения ждать скорее всего не стоит 🙂 Потрачено кароч.

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

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

Цитаты

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

Базовые тезисы:

[…] первое ложное допущение, лежащее в основе определения графика разработки, состоит в том, что всё пойдёт хорошо, то есть каждая часть работы будет продолжаться столько, сколько она «должна» продолжаться.

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

О программистах, «выросших» в менеджеров:

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

Но далее:

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

Привет аджайлам:

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

Про архитектуру:

Как отметил Блааув (Blaauw): «Там, где архитектура говорит о том, что происходит, имплементация говорит о том, как это сделано, чтобы оно произошло». В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и головки. Когда ребёнок усвоит эту архитектуру, он с одинаковой лёгкостью сможет определять время как по наручным часам, так и по часам на церковной башне. Имплементация же и его реализация описывают, что происходит внутри: передача усилий и управление точностью каждым из многих механизмов.

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

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

Древняя пословица предупреждает: «Никогда не выходи в море с двумя хронометрами; возьми один или три». То же самое явно относится к текстовым и формальным определениям. Если есть и то и другое, то одно должно быть стандартным описанием, а другое — производным, чётко обозначенным как таковое. Любое из них может быть первичным стандартом.

О насущном:

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

О деньгах:

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

Про организацию (прям инсайт для меня):

[…] закон Конвея (Conway): «Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации».

Про первую имплементацию:

Например, лабораторный процесс опреснения воды будет испытан на пилотной установке мощностью 10 тысяч галлонов в день, прежде чем его используют в коммунальной системе водоснабжения мощностью 2 миллиона галлонов в день.
Разработчики программных систем также получили этот урок, но, похоже, он ещё не усвоен. Из раза в раз каждый проект сводится к дизайну набора алгоритмов, а затем погружается в сборку программного обеспечения, поставляемого заказчику, по графику, требующему поставки первой вещи, которая будет создана.
В большинстве проектов первая построенная система едва пригодна для пользования. Она может быть слишком медленной, слишком большой, неудобной в использовании или всё вместе взятое. Никакой другой альтернативы нет, кроме как начать снова, болезненно, но умнее, и построить переработанную версию, в которой эти проблемы решаются. Отбраковка и редизайн могут быть сделаны одним махом или же по частям. Неважно как, но это будет, что и показывает весь большой системный опыт. Там, где используется новая концепция системы или новая технология, приходится разрабатывать систему, которая потом выбрасывается, потому что даже самое лучшее планирование не является настолько полным, чтобы всё получилось правильно с первого раза.

Об изменениях (в частности почему в разработке софта так всё сложно):

Косгроув (Cosgrove) проницательно отметил, что программист поставляет не какой-то материальный продукт, а удовлетворение потребностей пользователя. И реальная потребность, и восприятие этой потребности пользователем будут меняться по мере разработки, тестирования и использования программ.

И продолжение (ещё один инсайт):

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

Об управленцах и специалистах:

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

Немного охуительных советов (насколько очевидных, настолько же и всегда актуальных):

Как контролировать крупный проект по жёсткому графику? Первый шаг — иметь график.

И далее о планировании:

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

О прототипировании:

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

Про инкрементальную разработку:

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

О хороших и лучших программистах:

Мне давно нравится задавать кандидатам в программисты вопрос «где следующий ноябрь?». Если этот вопрос является слишком загадочным, тогда я предлагаю: «Расскажите мне о своей ментальной модели календаря». По-настоящему хорошие программисты обладают сильным пространственным чувством, у них обычно есть геометрические модели времени, и они довольно часто понимают первый вопрос без детализации. У них очень индивидуалистические модели.

О продуктивности и качестве:

Джонс говорит: «Нет. Сосредоточьтесь на качестве, и продуктивность последует». Он утверждает, что дорогостоящие и опоздавшие проекты инвестируют большую часть дополнительной работы и времени в отыскание и исправление ошибок в спецификации, дизайне, имплементации. Он предлагает данные, которые показывают сильную корреляцию между нехваткой систематического контроля качества и срывами графика. Я верю в это. Бём (Böhm) указывает на то, что продуктивность снова падает, когда преследуют предельное качество, как в программном обеспечении IBM для космического шаттла.

Про ООП:

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

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

О переиспользовании:

Йордон даёт оценку больших издержек: «Хорошее эмпирическое правило в том, что такие переиспользуемые компоненты потребуют в два раза больше усилий, чем „одноразовый компонент”».

И последнее:

Крупным достижением последних лет стала книга Демарко и Листера 1987 года «Кадровое обеспечение: продуктивные проекты и команды» (Peopleware: Productive Projects and Teams). Её основополагающий тезис заключается в том, что «основные проблемы нашей работы носят не столько технологический, сколько социологический характер».