Комментарии 34
«Девять женщин не родят ребенка за один месяц»
«Девять женщин не родят ребенка за 8 месяцев.»
Без разницы сколько программистов* мы возьмем — быстрее чиниться ничего не будет.
Есть задачи, которые можно масштабировать. Есть задачи, которые нельзя масштабировать. Как правило починка бага — та вешь, которая масштабируется плохо. Отдельная ошибка — кидать на решение бага человека, который с нужным куском кода не работал.
* — откуда вообще мнение, что там все баги программистские? Кривая логика квестов — это не программистский баг. Это геймдизайн, скриптовка.
Даже проваливающиеся через землю машины может быть ошибкой левелдизайна, а не кода физики.
Зато девять женщин родят девять детей за девять месяцев. Если есть потребность в большом количестве детей, то девять женщин намного производительнее, чем одна.
В данном случае есть потребность починить много багов.
Если считать все баги(и модели, и текстуры, и системы хранения/загрузки ресурсов игры на диске, и баланса оружия, и краевых моментов в физике машин, и ИИ) универсальными, и программистов универсально же универсальными — то да.
В реальности, увы, так бывает чуть реже чем никогда.
Но если 9 женщин в 100% случаях не смогут родить ребенка быстрее, то уж 9 программистов, скорее всего, сделают работу быстрее. Даже если будут работать не параллельно, а сменами. Конечно, зависит от задачи, программистов и прочих факторов.
Я это к тому, что сравнение с родами некорректно.
Впрочем, токари тоже друг за другом врядли возьмутся дотачивать.
Это аппеляция к авторитету. Он, кстати, не опирается на исследования, а просто приводит опыт своей работы в разработке. И, если я не ошибаюсь, как минимум технологии с тех пор изменились (а вообще — изменились процессы, появилась более глубокая специализация и так далее, так как я напомню, что оригинал издали в 1975 году).
По моему опыту, добавление разработчиков может улучшить релиз (но скорее незначительно, так как изначально планировалось 5*12=60 человекомесяцев, а здесь же стало 5*12+4*2=68 человекомесяцев, то есть не стоит расчитывать на более, чем 10% к общим ресурсам), если новые люди в команде являются опытными специалистами и не являются новичками в самой компании. И как дополнительное необходимое условие — достаточно хорошее покрытие тестами (в том числе интеграционными), разумная автоматизация и тд.
Если же в проекте все проверяется руками, билды налажены кое-как, контракты в коде выражены не строгой типизацей/тестами, а просто хранятся в памяти разработчиков, нет линтеров и каких-то style guide'ов и так далее, то действительно, новички будут входить в проект долго и скорее затормозят развитие проекта.
Это аппеляция к авторитету. Он, кстати, не опирается на исследования, а просто приводит опыт своей работы в разработке.
…
По моему опыту...
То есть, Ваш личный опыт и Ваша аппеляция к собственному авторитету против опыта и авторитета Брукса(и тех, кто по опыту своей практике с Бруксом скорее соглашается).
Я говорю, что нельзя приводить в пример книгу, которая даже не является научным исследованием, плюс в которой выводы делаются на основе IT 70х годов.
В качестве слабого подтверждения я привел свой пример (а я участвовал в таком изменении команды около 7 лет назад). Соответственно, для меня существует как минимум один контрпример.
В дополнение я привел агрумент (а не свой опыт), в котором демонстрируется технологическая разница в проектах, которая влияет на время "входа новичка в проект". Из-за развития IT, лет 50 назад (годы написания цитируемой книги) большая часть автоматизации (которую я привел в пример) отсутствовала, а значит новый человек тратил больше времени на "вход в проект", отвлекая бывалых сотрудников. Именно про это, кстати, и говорил Брукс. В современных IT проектах время входа может быть меньше (не всегда), а потому и добавление новых людей в проект может улучшить ситуацию (опять-таки — не всегда).
Как следствие из ненаучности изначальной книги и довольно старых практик, контрпримера и аргумента про технологии я далее сделал вывод, что нельзя слепо следовать как минимум этому доводу из книги (пусть даже и довольно популярной).
Однако, так как у меня тоже нет под рукой исследований, я не смогу построить корректную модель. Я только могу сказать, какая модель "стала менее корректной".
То есть они ещё не исправили все баги, а уже дополнение лепят?
Если следы недовырезанного метрополитена глючат из-за того, что его криво обрезали, то легче вернуть его в игру, чем обрезая в спешке получить ещё глюки.
То есть они ещё не исправили все баги, а уже дополнение лепят?кажется, это будет скорее не «дополнение» а «функционал, который пользователи ожидали, а разработчики не успели затащить в релиз».
А вообще конечно же хочется чтобы сюжетные дополнения для CP77 были на уровне таковых в ведьмаке.
историю о Найт-Сити в начале 2021 годаЖаль, что всё не так, как казалось сначала.
со скидкой
в егс
CD Projekt Red показала тизер первого дополнения к Cyberpunk 2077