Комментарии 17
Вынашивание ребёнка занимает девять месяцев, независимо от того, сколько женщин поставлено выполнять задачу.
Закон Амдала же.
Действительно есть схожие моменты. Оба про распараллеливание говорят.
У Брукса всё-таки про то, что есть задачи, которые невозможно распараллелить. А у Амдала про скорость выполнения распараллеленных задач.
Закон Амдала я бы проиллюстрировал такой фразой: караван идёт со скоростью самого медленного верблюда.
Закон Амдала я бы проиллюстрировал такой фразой: караван идёт со скоростью самого медленного верблюда.
Не соглашусь, ну да ладно. На самом деле изначально хотел написать довольно длинный комментарий с отсылками на Java Concurrency In Practice, но решил ограничиться отсылкой к закону Амдала.
Вообще, давно во мне коготком зацепилось убеждение, что если взять всех мэтров, Брукса, Мартина, Фаулера, Рейнвотера, etc..., то, по большому счёту, пишут они об одном и том же. Точнее одно и то-же о разном. О "как-бы" разном, но подчиняющемся одним и тем же законам. Читаешь про управление людьми — тут и там параллели к чистой архитектуре, читаешь про многопоточность — тут и там про проектную деятельность.
Книга “мифический человеко-месяц”, заслуживает того, чтобы её читали и перечитывали, издавали и переиздавали.
Почему? Nullius in verba.
Который раз книгу превозносят, как нечто ах-ах, хотя ничего сверхкрутого в ней нет. Автор запорол большой проект в IBM, сделал некоторые выводы — молодец. Что дальше?
Конечно книга эта не червонец, чтобы нравится всем, и в ней есть спорные, а есть неактуальные моменты. Почему её превозносят? За всех не отвечу, скажу за себя.
Я нашёл в ней ответы на некоторые вещи которые мне были непонятны. Например, мне было непонятно почему при найме многие гоняются за некими soft scills (я всегда относился несерьёзно, в духе, лишь бы код писать умели, ведь мы пришли работу работать, а не отношения выстраивать), а микросервисная архитектура стала предметом хайпа.
У Брукса нашёл ответ в виде объяснения, что ахиллесова пята - эта взаимодействие между людьми, соответственно, что бы взаимодействие шло как по маслу нужны те самые софт скилы, а чтобы взаимодействия было меньше, нужно раздробить проект, и пусть над каждым микросервисом работает хоть по одному человеку - лишь бы внешний контракт исполнил.
Более того, можно попытаться использовать это утверждение чтобы заглянуть в будущее. Что станет предметом хайпа после микросервисной архитектуры предсказать не берусь, а вот стереотип о том, что программисты это какие-то интроверты которые угрюмо сидят в своих тёмных подвалах, плавно сменится (и уже проделал огромный путь) стереотипом, что это наоборот, такой человек-тамада, ибо софт скиллы зашкаливают.
Идея не нова, может кому-то она очевидна и без Брукса.
Одна голова хорошо, а две лучше
есть дополнение: а три еще хуже.
Это сказано ниже:
У семи нянек дитя без глазу
Единство «Принципов работы» системы System/360 проистекает из того, что принадлежит перу только двух человек.
ИМХО почти серебряная пуля есть (ну, не из очень чистого серебра). Книга Брукса это подтверждает своим названием. Основной пинцип в том, что главные интересы заказчика совпадают с интересами исполнителя (только заказчик не всегда это понимает). В частности, нужно всеми силами избегать долгосрочного планирования. Заключать договор о расценках, а не о сроках. В крайнем случае ген.план должен предусматривать возможность поправок. А планировать только на пару месяцев. С регулярными отчетами и согласованием дальнейшего 2х месячного плана. Совпадение интересов: исполнитель не хочет нарушать график работ, рискуя расторжением договора, заказчик хочет получить хороший продукт, а не халтуру, которую ему может впарить, загнанный в угол, исполнитель. Кроме того на старте закаказчик не может дать абсолютно детальное ТЗ, а если выдаст, что-то похожее (на 10 тысячах страниц), то исполнитель будет отметать дальнейшие пожелания заказчика. Могут открыться и объективные проблемы в ходе работ. В ТЗ могут обнаружиться противоречия, требования могут оказаться невыполнимы для данной платформы и т.д.
интересы заказчика совпадают с интересами исполнителя
Нигде и никогда они не совпадают. Иполнитель заинтересован в том, чтобы как можно больше денег получить от заказчика. Заказчик заинтересован в том, чтобы как меньше денег потратить на проект (как можно меньше денег дать исполнителю), при этом получить качественный (что бы под этим не подразумевалось) результат.
[нужно] заключать договор о расценках, а не о сроках
Такой договор гарантирует результат, но не качество (привет, российская тендерная система).
В этой ситуации исполнителю выгодно либо сделать как можно быстрее (если платят за выполнение проекта), либо как можно дольше (если платят за работу над проектом — выгодно размазывать эту работу на максимальный срок).
Правда в том, что в IT мы не умеем управлять ни сроками, ни качеством.
Модели из мира производства помогают наладить некий процесс, но этот процесс не может гарантировать ни качество (мы не умеем его измерять), ни сроки (мы не умеем ими управлять).
Я полагаю, что это не только в IT.
Заказчик заинтересован в том, чтобы как меньше денег потратить на проект (как можно меньше денег дать исполнителю), при этом получить качественный (что бы под этим не подразумевалось) результат.
Я отметил, что
(только заказчик не всегда это понимает).Бывают безграмотные заказчики, которые за копейки хотят получить ОС сравнимую по сложности с OS 360. За неразумно минимальную цену им согласятся делать только аферисты, которые планируют их кинуть.
—
либо как можно дольше (если платят за работу над проектом — выгодно размазывать эту работу на максимальный срок).
Я отметил, что
исполнитель не хочет нарушать график работ, рискуя расторжением договора
—
привет, российская тендерная система.
Модели из мира производства помогают наладить некий процесс, но этот процесс не может гарантировать ни качество (мы не умеем его измерять), ни сроки (мы не умеем ими управлять).В книге, о которой статья, речь про США. И я про США. Но не только — за 1000 баксов в месяц кодер в Индии будет землю рыть, только бы не потерять эту работу.
Любой заказчик при прочих равных предпочтёт платить меньше, а любой исполнитель заинтересован в том, чтобы за свою работу получать как можно больше.
Этот конфликт интересов существует, и не зависит от грамотности сторон, национальности, расы, вероисповедания, и чего бы то ни было ещё.
И поэтому утверждение "интересы заказчика совпадают с интересами исполнителя" не верно в корне, а без него все возможные модели сыпятся.
Всё упирается в упомянутые прочие равные, которые не равные у, например, демпингующего студента и у опытного разработчика. Только заказчику они не известны (см. рынок лимонов), и становятся предметом доверия.
Любой заказчик при прочих равных предпочтёт платить меньшеКлючевые слова «при прочих равных». Предположим, что средняя цена создания ОС равна N баксов (более точные цифры можно поискать в сетке). Если Вы предложите в 1000 раз меньше, никакие солидные разрабы не откликнуться на Ваше предложение. А аферистов всегда и везде много.
Этот конфликт интересов существует, и не зависит от грамотности сторонДа, существует. Но при этом закзчик хочет хорошей и быстрой (на сколько возможно) работы. Для этого он может стимулировать исполнителя премиями и т.п. (в разумных пределах).
Всё упирается в упомянутые прочие равные (которые не равные у, например, демпингующего студента и у опытного разработчика)Если заказчик не может отличить студента от опытного разработчика, то заказчик ИМХО безграмотный.
Да, я понимаю о чем вы говорите.
В то же время, я не согласен с тем что даже самый матёрый заказчик с этим что-то может сделать: его проект могут отдать на аутсорс тем же школьникам и студентам, и тут не поможет ни ориентирование по ценам (взяли по рыночному прайсу -> отдали проект на аутсорс), ни какие-то другие факторы: ни хорошее портфолио, ни репутация исполнителя, ничего, в общем-то, не гарантируют.
его проект могут отдать на аутсорс тем же школьникам и студентамМогут. Но это сделает Исполнитель, с которым договор. Если проект сложный, Исполнитель рускует сильно намучиться со своими студентами-школьниками. А по очету за 2 прошедших месяца Заказчик захочет выслушать доклад ведущего спеца от исолнителя, а не от неизвестного ему школьника. Да и какой исполнитель в здравом уме доверит школьнику делать такой доклад? Пара элементарных вопросов, на которые докладчик не ответит. И возникнет реальная угроза расторжения договора. При этом проваленный проект может сильно испортить репутацию фирме-исполнителю, не говоря об упущенной выгоде и реальных потерь денег.
согласен существует, но от грамотности сторон зависит, потому как люди обучаемы,
грамотный заказчик к примеру знает, что «жадный платит дважды» и дела с ним вести будет проще
Самая большая ошибка в концепции «Создавать так, чтобы потом выбросить» заключается в том, что она неявно исходит из классической последовательной, или водопадной, модели сборки ПО.
Глава 11 — не единственная испорченная последовательной водопадной моделью; эта ошибка проходит через всю книгу, начиная с правила планирования временного графика в главе 2
А в главе 16, где рассматриваются кандидаты в серебряные пули, об этом тоже упоминается в пункте «уточнение требований и быстрое прототипирование»:
В задаче сборки программного обеспечения одним из наиболее многообещающих современных технологических усилий, которое затрагивает существенные, а не случайные признаки, является разработка подходов и инструментов для быстрого прототипирования систем как части итеративного процесса разработки спецификаций.
Поговорка «Одна голова хорошо, а две лучше» вошла в русский язык в 20 веке от английской поговорки: Two heads are better than one (Две головы лучше, чем одна).
В русском языке есть близкая пословица: Ум хорошо, а два лучше
Делу время, потехе час! Тезисы «мифического человеко-месяца» Фредерика Брукса, в пословицах и поговорках