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

PD>С чего вдруг ? При их способе написания они просто в эти 16 Мбайт не уложатся. Хоть 4 машины поставь, хоть 16. Они могут написать более медленный код, и тогда да, добавлением машин можно проблему решить. Но если уж в ограничения по памяти не уложатся, то новые машины тут не помогут. Или разбить процесс на несколько машин и устроить их взаимодействие ?
Конечно. Точно так же, как и для роста быстродействия.
PD>Ну тогда они в сроки не уложатся, да еще и вопрос, сумеют ли вообще сделать.
Ну так и отлично — тогда проект отдадут тем, кто сможет.

PD>Он не идиот, он дилетант. Теперь он понял, что в М можно уложиться. А до этого не знал.
PD>И понял лишь потому, что ему такие требования эта команда типа 3 выставила. С 4 машинами, как ты предлагаешь (допустим, что это все же удалось бы сделать). Он и теперь не знает, что можно было с одной машиной сделать, если бы делала команда 1
Да, не знает. Но точно знает, что 8 машин — избыток.
PD>>>Дальнейшее.

PD>Ну вообще-то я рассматривал варианты. Если делала команда 1 или 2, то по окончании проекта команда разошлась.
Не-не-не. Проект отдали команде 3. Что в это время происходит с командами 1 и 2?
Разбегаются из-за невостребованности?

PD>Заказчик, если ему первый проект делала команда 3, уже уверен, что именно такие ресурсы нужны. И выставит такие же требования на новый проект, умножив на 2, так как новый проект сложнее.
Зачем он будет умножать на 2? Он точно так же выставит бизнес-требования (я надеюсь, я достаточно понятно объяснил, откуда берутся бизнес-требования, и мне не придётся ещё раз это пересказывать?).
И точно так же команды будут предлагать решения с разными потребностями в памяти и процессорной мощности.

PD>И скорее всего обратится в ту же фирму, они же все сделали, можно им и опять поручить. Ну а если он все же решится устроить конкурс, то для начала выставит те же требования, что и в прошлом проекте * 2. Что при этом скажет потенциальная команда типа 1 — не знаю. Может, и ответит, что 8 машин тут не надо и 200 единиц стоимости тоже, а хватит и 1 машины и 100.
Напомню, что в предыдущем проекте количества машин среди требований не было. И в новом не будет.
PD>Может, и нет. Зачем себе проблемы создавать, да и лишние 100 единиц не помешают. И сделать можно в стиле команды 3, раз уж такие ресурсы предлагают.
Неа. Команде 1 нужно очень прогнуться, потому что у команды 3 есть значительное конкурентное преимущество — сделанный проект. Поэтому если предложить те же условия, то ты точно, с гарантией пролетишь на тендере.
Надо предложить прямо существенное отличие — по срокам, стоимости, или эффективности.
А если вы не готовы напрягаться, или не можете показать реальный экономический эффект — то нефиг и жаловаться, что работу отдают не вам, а недоучкам, пишущим неэффективный код.

PD>Вполне могу согласиться. Но почему они в дефиците ? А именно потому, что команды типа 3 смогут сделать при этом железе, а в результате это станет нормой, и команды типа 1-2 будет просто не из кого собрать.
Нет, не поэтому. А потому, что переход на каждый следующий этап "могу написать программу, которая работает иногда", "могу написать программу, которая работает всегда", и "могу написать программу, которая работает всегда и очень эффективна" требует x10 усилий и времени.
Невозможно с нуля стать сениором за шесть месяцев, увы. А стать джуниором — можно. Было бы можно стать сениором за полгода — джуниоры не смогли бы устроится на работу.
Все компании, где я работал последние 15 лет, говорят: "мы бы хотели брать супер-специалистов, но на рынке их нет. Единственный способ — это брать с улицы и обучать самим".

PD>Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения
Деградация отрасли — это потеря денег. Пока в отрасли крутятся триллионы, с ней всё в порядке.
Если посмотреть в абсолютных цифрах, то специалистов по эффективной разработки стало не меньше, а больше. И софта эффективного стало больше.
Просто помимо этого эффективного софта есть ещё x10000 софта, который не удовлетворяет нашим высоким моральным требованиям. И это прекрасно.
Потому что сениоры — они не из воздуха берутся; это джуниоры, которые научились и выросли. И вчерашний джун — это гораздо более удачная заготовка для сениора, чем просто человек со стороны.

PD>Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало.


PD>Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся.
Вообще не закончится. Будет весь спектр. Это как, скажем, с одеждой. Рынок завален низкокачественным ширпотребом. Но если надо — по-прежнему можно купить хорошую вещь.

PD>Ну это особый разговор. Я же написал — все 3 команды могут сделать вполне корректно работающее ПО. Если это не выполняется, то говорить не о чем.