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

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

Так я об этом и говорил — команда типа 3 просто не смогла бы его сделать, и увеличение количества машин тут не помогло бы.

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

А откуда ? Вот представь себе, что команда типа 3 все же сделала по твоему алгоритму, только машин им понадобилось бы не 4, а 8. Все, теперь заказчик знает, что нужно 8.

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

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

Ты, видимо, не понял. Не было 3 команд. Я рассматривал варианты — либо собрать команду типа 1, либо типа 2, либо типа 3. В итоге есть одна команда, какого-то типа, ей и поручили.


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

Да нет, не надо. Я же писал — новая задача сложнее примерно в 2 раза. Это заказчик и сам может оценить, по набору фич. Вот он, базируясь на прежнем проекте, и умножает на 2. Бизнес-требования удовлетворяются, допустим.

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

Я вообще о количестве машин не писал, это твое. И по твоему алгоритму сделали (допустим) на 4 машинах. Ну а тут сам бог велел согласиться и на 8.

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

Верно. У команды 3 есть преимущество — она прошлый проект сделала. Черт-те как, но сделала. К ней и обратятся, скорее всего. А команду типа 1 возьмут только если она предложит сделать с меньшими расходами.

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

А кто говорит про 6 месяцев ? Я вот что писал (для команды типа 2)

PD>Сеньоры команды 2 будут работать надо следующим проектом, с ними все хорошо. Юниоры команды 2 чему-то научатся, и если не в следующем, то через пару проектов сами станут грамотными сеньорами.

S>Все компании, где я работал последние 15 лет, говорят: "мы бы хотели брать супер-специалистов, но на рынке их нет. Единственный способ — это брать с улицы и обучать самим".

Совершенно согласен. Я этим и занимался последние 10 лет, в Школе, которую мы создали в омской фирме. Правда, я доводил их до юниора, а дальше делали уже другие люди, но именно так. Есть среди них и сеньоры, есть и архитекторы.

PD>>Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения
S>Деградация отрасли — это потеря денег. Пока в отрасли крутятся триллионы, с ней всё в порядке.

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

S>Если посмотреть в абсолютных цифрах, то специалистов по эффективной разработки стало не меньше, а больше. И софта эффективного стало больше.

Ну по сравнению с тем, что было 10 лет назад — да, конечно. В N раз больше. Вот только неэффективного стало в KN раз больше.

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

Если они пришли из команды типа 2 — да. А если из команды типа 3 — нет. Точнее, они многом, конечно, научились, но вот писать эффективно не научились. Негде было.


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

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