Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Я такое давал своим детям несколько лет назад, кроме рекурсии. Это была настольная игра. Дочка только-только пошла в школу и нормально справлялась.
Есть координаты настольной игры?

S>>Мы говорим не о принципах принятия решения, а о наличии влияния яп на качество результата. Ты выяснил, что влияет, даже если ни одной строчки еще не написали. А ты говоришь, во втором десятке факторов!

I>Влияет, но только после принятия решения, и никак не раньше и поправить/скомпенсировать часто уже нет возможнсти.
I>Человек, который принимает решения определяет вообще всё, соответсвенно степень влияния менеджмента выше любых технических вопросов. Например, менеджер не только может принять решение о технологии, но и может убрать бюджет из разработки и передать в тестирование "а для багфикса студентов наймём"
Конечно, но когда я сравниваю влияние яп, я пытаюсь мысленно изолировать все остальные факторы. Т.е. берем 2 равные команды и при прочих равных одной даем писать на одном языке, другой — на другом.
I>Более того в ряде случаев менеджмент выше даже требований, если менеджеру вздумается разбавлять эти требования отсебятиной. В данном случае наличие такой отсебятины определяет качество задолго до того, как требования будут готовы.
I>Пример из жизни, менеджер и архитект по совместительству: "давайте на нетворк драйв поместим Хромиум портабл, что бы юзерам не надо было ни инсталировать, ни копировать". А тот факт, что Хромиум так работать не может, его не сильно интересует, и менеджер включает "гестапо": "Крешится Хромиум — вы неправильно ваш жээс пишете, не надо мне сказки рассказывать".
I>В итоге — полгода война между менеджером и командой разработчиков закончилась пирровой победой разработчиков, а времени на внятное решение уже нет.

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

I>Или такие варианты:
I>"А давай ты до конца митинга вот эту фичу запилишь"
I>"Мы договорились на месяц, но надо сделать за 10 дней, + дополнительно две новые фичи, что бы показать какие мы крутые"
I>"Давай ты за выходные дофиксишь баклог"
I>Надо объяснять, что все функционалисты выпилились из того проекта?
Если можно выпиливаться, то в порядке вещей вообще выпиливаться из такого проекта, невзирая на парадигму. Выглядит так, будто функционалисты оказались прошареннее.

S>>Принятие решения (у меня по-крайней мере) — процесс итерационный. Выкатываешь продукт, требования меняются с ростом эксплуатации, старое решение не тащит. Тут и начинается самое интересное в принятии решений.

I>Некоторые решения необратимы. Например "у нас на бенче 100 джаваскрипт сеньоров, будем писать на node" Наличие таких мер влияет на качество гораздо сильнее парадигмы.
Безусловно. Но кто заставляет держать таких решал на местах, где они принимают такие решения? Это же просто враги любой разработки, не говоря уж о бизнесе.