Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот и отлично. Заказчик тут меня мало интересует, с ним понятно.
Ну, ок. Всего-то за десяток постов мы таки выяснили, что исходный вопрос

Автор: Pavel Dvorkin
Дата: 25.02.24

был малоинтересен.
PD>А вот 80 можно распределить несколькими способами
PD>Обращаю внимание на то, что во всех этих вариантах предполагается, что результат заказчика удовлетворит по ТЗ. Все будет сделано и будет работать.
PD>Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит.
Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет.
Да всё есть. Просто нужно будет поставить не одну машину с 16 Мбайт, а четыре машины по 16 Мбайт каждая. Это даст разницу в полном Z для вариантов 1, 2, и 3.
PD>А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же.
Всё верно.

PD>А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично.
С чего это "быть не может"? То, что заказчик — не инженер, не означает, что он идиот.
Из того, что есть программа с требованиями M означает ровно одно — в M можно уложиться. Теперь, когда у заказчика или его конкурента возникает аналогичная задача, инженеры не смогут сказать "нам нужно 2M" — заказчик показывает им готовое решение и говорит "ну ведь вот эти уложились в M, значит и вы уложитесь".

PD>Дальнейшее.

PD>Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть.
Всё верно.
PD>А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен.
Всё верно.
PD>Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма.
Конечно.

PD>И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством.
А куда делись команды 1 и 2? Заказчик прекрасно понимает, что монополизация рынка — это плохо, и при прочих равных всё равно запросит коммерческие предложения от всех трёх команд.
И если окажется, что в новом проекте команды предлагают разные результаты, то выиграет более профессиональная команда. Так работает рынок.
PD>Вот поэтому мы и имеем, что имеем.
Нет, мы имеем то, что имеем, ровно по одной причине — железо стало дешёвым. В реальности окажется так, что команд типа 1 — раз-два и обчёлся. Они готовы взяться за проект, и сделать его быстро и качественно. Но — не сейчас. Сейчас они уже заняты. Приходите к нам через пару лет — и мы вам всё сделаем. Особенно если вы прямо сейчас внесёте предоплату. А если хотите прямо сейчас — то платить сеньорам надо будет не по 20, а по 40. Они же в дефиците, значит разрыв в зарплате между сеньорами и юниорами будет гораздо более значительным. Открытый рынок балансируется ровно так, чтобы экономия на аппаратуре компенсировалась ростом затрат на фонд оплаты труда.

Мы с вами можем сколько угодно ныть о том, что современная разработка деградировала. Я сам это прекрасно вижу — взять любую "контрольную панель", поставляемую вместе с железками. Что видеокарты, что принтеры — оно же всё ужасное. Гигабайт кода, который помимо умения "переключиться со встроенного видеопроцессора на дискретный" показывает сотни анимированных диалогов, глючит, падает, и тащит с собой две версии питона, джава-машину, и node.js.
Да, печальное, унылое зрелище. Но — то, что оно такое, означает, что большинство участников рынка это устраивает. Переход к оптимальному и устойчивому софту не даёт зримого конкурентного преимущества, увы.

Помимо этого, есть эффект ограниченной информации. Идеальный баланс работает только в идеализированной модели "полной и достоверной информации", которая в жизни не встречается. Заказчик скорее отдаст заказ команде, с которой есть предыдущий успешный опыт — потому что альтернативные команды обещать-то могут всё, что угодно — в том числе и M/2 памяти и T/3 сроков. А потом окажется, что "не получилось" ни M ни T.
Или заказчик был бы готов заказать команде, которая предложит M/2 памяти и T/3 сроков, но он просто не нашёл такую команду. Не успел / не смог / не знал, что такая команда вообще есть.

Вот с этими аспектами и стоит бороться — распространять информацию о том, как писать эффективный код. Писать и пропагандировать фреймворки, которые позволяют писать оптимальный код даже нубам, которые сами не очень понимают, как там оно устроено под капотом, и всё ещё с гарантиями корректности получающегося кода.
Потому что, как ни удивительно, требования производительности идут после требований корректности. Никому не нужна программа, которая тратит M/10 памяти, но в половине случаев даёт неверный результат, или падает.
Помнится, когда мы проверяли смелую гипотезу о том, что на linq нельзя написать эффективную реализацию бинаризации Савола, в исходном C++ коде нашлась пара ошибок. Ну, просто они не стреляли достаточно зрелищно, поэтому автор их так и не заметил