Сколько еще Мистического Человеческого Месяца по-прежнему применяется?

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

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

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

Ответ 1

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

Однако некоторые вещи не выдержали испытания временем. Я не верю, что написание диаграмм ASCII в вашем коде - хорошая идея, и предложенный подход "хирургической команды" был опробован несколькими людьми (Чарльз Симони в MS, самый классный) и обнаружил, что он не слишком хорошо работает.

Ответ 2

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

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

Ответ 3

Разве это не похоже на то, что Sun Tzu Art of War по-прежнему применима к войне, поскольку у нас есть современное оборудование?

Ответ 4

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

Ответ 5

Оба знаменитых произведения Брукса "Никакая Серебряная Пуля" и "Мифический Человек-Месяц" - это объяснения фундаментальных ограничений в языках программирования и управлении проектами соответственно.

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

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

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

Лично я читал книгу только для раздела "Радости ремесла". Я никогда не читал ничего такого, что так элегантно описывает, какое программирование у него лучше всего. (Если вам интересно, это на стр. 7 и можно просмотреть в функции amazon.com "Посмотри внутрь!" )

Ответ 6

Я, конечно, думаю, что такие вещи, как "No Silver Bullet", так же применимы сегодня, как и десятилетия назад, тем более, что мы видим, что все больше и больше молодых людей приходят в индустрию и думают, что x - это новейший и самый лучший язык/технология убийцы и все из-за этого будут умирать другие технологии.

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

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

Ответ 7

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

Спольский обсуждает "версию 2" по-своему. Я не помню, если он специально связывается с МММ, но он очень похож по понятию.

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

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

Ответ 8

Прочитайте TMM как книгу, в которой изложена проблема, возможно, проблема в разработке программного обеспечения: ее не технология, ее люди! Все улучшения, о которых вы говорите spring, из этой основной реализации. Они все на месте, чтобы решить проблемы, изложенные Брукс. Это книга, в которой я уверен, что Кент Бек и Уорд Каннингем и Алистер Кокберн и Мартин Фаулер все прочитали, приняли близко к сердцу, а затем начали создавать свои серебряные пули.

Ответ 9

Я считаю, что это одна из книг "обязательно читать" для всех, кто хочет понять процесс разработки программного обеспечения.

Ответ 10

Потребность в рабочей силе развития быстро растет за последние 40 лет, и эта потребность не прекратится. Поскольку уровень умных (см. Joels "умный и делающий" ) люди в населении остаются в целом одинаковыми, каждый год обучение все больше и больше разработчиков означает, что средняя умность разработчика снижается.
40 лет назад это были полубоги, которые стали разработчиками; 20 лет назад, это была работа для умных людей, а теперь, когда я смотрю на молодых студентов CS в моей Alma Mater, кажется, что они берут всех, кто знает, что такое компьютер.
Это не означает, что надвигается катастрофа - западный мир продолжает импортировать умных людей (или аутсорсинговую работу) с развивающихся рынков или стран третьего мира. Новые средства разработки облегчают разработку хороших приложений. Эти факторы, похоже, нейтрализуют друг друга, делая MM-M вечным.

Ответ 11

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

Ответ 12

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

Ответ 13

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

Технические примеры почти полностью устарели и имеют смысл только в том случае, если вы думаете о системе 0.034 MIPS/360 1964 года. Когда у вас есть только 8 КБ памяти, предполагая, что пользователь должен нести ответственность за обработку високосных лет, вместо того, чтобы тратить 26 байт системной памяти (как это делал Брукс), но сегодня это кажется совершенно глупым. Сегодня я не знаю, какая небольшая система - ваш телефон в тысячи раз более мощный, чем самая мощная система OS/360. Сегодня мы знаем гораздо больше о юзабилити и взаимодействии с человеком и компьютером, и заставить пользователя отвечать за эту категорию вещей просто сумасшедшим.

Ответ 14

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

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

Ответ 15

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

Нет замены для планирования (произносится как shed-uling), планирования и достойного управления.

Как и большинство из этих "один лайнеров" или "золотых правил", рассмотрите их больше рекомендаций (с контекстом), чем в камне.