Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Прочие равные это условия задачи покрываемые возможностями инструментов.
НС> Т.е. если для одной задачи есть два разных инструмента, оба потенциально применимые для решения задачи, но при этом один привычнее, а другой эффективнее для данной задачи, ты без вариантов выберешь привычный, так?
Интересно, откуда ты взял сферовакуумную эффективность (расскажи, на чем сегодня наиболее эффективно писать виндогуй )? Рассуждать об эффективности инструмента в отрыве от опыта использования это вообще смешно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Интересно, откуда ты взял сферовакуумную эффективность
НС> Я ее вообще не брал.
Да ты только что о ней стал рассуждать А рассуждать об эффективности без конкретики, это уже демагогия. Опять же эффективность она какая? Эффективность разработчика использующего инструмент (а она целиком и полностью зависит от опыта), или же эффективность решения созданного с помощью инструмента (но всегда есть пределы допустимого)? Но как бы там ни было, при определении критериев, сильно сомнительно получить, в результате, один единственный инструмент.
НС> H> (расскажи, на чем сегодня наиболее эффективно писать виндогуй )?
НС> Зависит от кучи факторов.
И самый главный из них — знакомство с инструментом.
НС> H> Рассуждать об эффективности инструмента в отрыве от опыта использования это вообще смешно.
НС> А я и не говорю в отрыве. Я пытаюсь понять, что это за такие мифические "прочие равные", когда привычность инструмента это единственный фактор выбора.
Кто говорит о единственном? Я сказал о решающем, при прочих равных. Что непонятного?
Здравствуйте, hattab, Вы писали:
НС>> Я ее вообще не брал.
H>Да ты только что о ней стал рассуждать
Не передергивай. Я как раз говорил о том, что факторов целая куча, и привычки среди них не самый главный.
H> А рассуждать об эффективности без конкретики, это уже демагогия.
Зато о лагерях нет, не демагогия.
H> Опять же эффективность она какая?
Обычная — максимально качественный код минимальными ресурсами. А у тебя есть другие варианты?
H>Но как бы там ни было, при определении критериев, сильно сомнительно получить, в результате, один единственный инструмент.
А я ни разу и не говорил, что единственный. Вот только в итоге какой то выбрать надо. И хорошо, если один из оптимальных с технической точки зрения инструментов совпадет с предпочтениями команды. А если нет?
НС>> Зависит от кучи факторов.
H>И самый главный из них — знакомство с инструментом.
Докажи, что самый главный.
НС>> А я и не говорю в отрыве. Я пытаюсь понять, что это за такие мифические "прочие равные", когда привычность инструмента это единственный фактор выбора.
H>Кто говорит о единственном? Я сказал о решающем, при прочих равных. Что непонятного?
Непонятно, что ты подразумеваешь под прочими равными.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Да ты только что о ней стал рассуждать
НС> Не передергивай. Я как раз говорил о том, что факторов целая куча, и привычки среди них не самый главный.
Ты же сказал, что вот один инструмент эффективнее другого. Откуда взялась эта эффективность, если с другим инструментом ты можешь быть не знаком?
НС> H> А рассуждать об эффективности без конкретики, это уже демагогия.
НС> Зато о лагерях нет, не демагогия.
Конечно нет Ты посмотри в профили местных юзеров, многие себя позиционируют, как специалистов широкого профиля, которым пофиг на чем писать? Нет. Пишут .Net разработчик, С++, Delphi и так далее.
НС> H> Опять же эффективность она какая?
НС> Обычная — максимально качественный код минимальными ресурсами. А у тебя есть другие варианты?
Есть. Эффективность решения задачи эндюзера. Наскоро сговняконый прототипчик, может задачу решать, но делать это не эффективно.
НС> H>Но как бы там ни было, при определении критериев, сильно сомнительно получить, в результате, один единственный инструмент.
НС> А я ни разу и не говорил, что единственный. Вот только в итоге какой то выбрать надо. И хорошо, если один из оптимальных с технической точки зрения инструментов совпадет с предпочтениями команды.
Вот это и есть ситуация, когда, при прочих равных, существуют несколько подходящих инструментов. И именно о такой ситуации я твержу с самого начала.
HC> А если нет?
Либо другую команду, либо другую задачу, либо переучивать команду (если ты думаешь, что это серьезно и реально)
НС> НС>> Зависит от кучи факторов.
НС> H>И самый главный из них — знакомство с инструментом.
НС> Докажи, что самый главный.
Да тут и доказывать ничего не нужно Я тебе уже предлагал рассмотреть ситуацию с виндогуем. Сейчас гуевых библиотек достаточно много, вот как будешь оценивать эффективность применения одной из них, без изучения? Да никак. Они все разные, у всех свои заморочки и без знания деталей, кидаться в омут головую может только самоубийца. В остальном точно также
НС> НС>> А я и не говорю в отрыве. Я пытаюсь понять, что это за такие мифические "прочие равные", когда привычность инструмента это единственный фактор выбора.
НС> H>Кто говорит о единственном? Я сказал о решающем, при прочих равных. Что непонятного?
НС> Непонятно, что ты подразумеваешь под прочими равными.
Когда задача решается несколькими инструментами с допустимой эффективностью.
Здравствуйте, hattab, Вы писали:
НС>> Не передергивай. Я как раз говорил о том, что факторов целая куча, и привычки среди них не самый главный.
H>Ты же сказал, что вот один инструмент эффективнее другого. Откуда взялась эта эффективность, если с другим инструментом ты можешь быть не знаком?
Для этого у нас к оценке привлекаются эксперты.
НС>> Зато о лагерях нет, не демагогия.
H>Конечно нет
Кто бы сомневался.
H> Ты посмотри в профили местных юзеров, многие себя позиционируют, как специалистов широкого профиля, которым пофиг на чем писать?
При чем тут профиль? В профиль пишут просто чтобы другим обри совать свой круг максимальной компетенции.
НС>> Обычная — максимально качественный код минимальными ресурсами. А у тебя есть другие варианты?
H>Есть. Эффективность решения задачи эндюзера.
Какое это имеет отношение к эффективности разработки? Или, по твоему, инструменты разработчика, которые мы тут обсуждаем, предназначены для решения "задачи эндюзера"?
H>Вот это и есть ситуация, когда, при прочих равных, существуют несколько подходящих инструментов. И именно о такой ситуации я твержу с самого начала.
А если, как это часто бывает, твоих "прочих равных" не получается?
HC>> А если нет?
H>Либо другую команду
Т.е. при необходимости смены средства разработки на одну задачу предлагается нанять еще одну команду? Смело. И на что только не пойдешь, чтобы обосновать неуместное фанатство.
H>либо другую задачу
НС>> Докажи, что самый главный.
H>Да тут и доказывать ничего не нужно
Демагогия.
H> Я тебе уже предлагал рассмотреть ситуацию с виндогуем.
Нет такой ситуации. Ты сам тут много рассказывал, что вне конкретной задачи рассуждать об эффективности нельзя. И тут же предлагаешь мне что то рассказать про крайне общую ситуацию. Это, батенька, не совсем корректные приемчики, однако.
НС>> Непонятно, что ты подразумеваешь под прочими равными.
H>Когда задача решается несколькими инструментами с допустимой эффективностью.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Ты же сказал, что вот один инструмент эффективнее другого. Откуда взялась эта эффективность, если с другим инструментом ты можешь быть не знаком?
НС> Для этого у нас к оценке привлекаются эксперты.
И сколько экспертов советовали тебе писать парсер на питоне?
НС> При чем тут профиль? В профиль пишут просто чтобы другим обри совать свой круг максимальной компетенции.
Человек себя позиционирует, как X-разработчик. Это и есть приверженность инструменту X. Это конечно не значит, что плюсист станет делать сайт на плюсах, но приоритеты явно обозначены.
НС> H>Есть. Эффективность решения задачи эндюзера.
НС> Какое это имеет отношение к эффективности разработки? Или, по твоему, инструменты разработчика, которые мы тут обсуждаем, предназначены для решения "задачи эндюзера"?
Нет блин, они предназначены для того, чтоб ыксперты могли их советовать программистам Задача эндюзера это самое важное. В конце концов программисты для эндюзера, а не эндюзер для программистов.
НС> H>Вот это и есть ситуация, когда, при прочих равных, существуют несколько подходящих инструментов. И именно о такой ситуации я твержу с самого начала.
НС> А если, как это часто бывает, твоих "прочих равных" не получается?
Так ведь ты сам соглашался, что одного единственного инструмента под задачу нет.
А я ни разу и не говорил, что единственный. Вот только в итоге какой то выбрать надо
Забыл?
НС> Т.е. при необходимости смены средства разработки на одну задачу предлагается нанять еще одну команду? Смело. И на что только не пойдешь, чтобы обосновать неуместное фанатство.
Фанатство ты выдумал. Как я уже говорил, обычно такого дурдома не происходит т.к. универсальный инструмент решает огромный спектр задач.
НС> H> Я тебе уже предлагал рассмотреть ситуацию с виндогуем.
НС> Нет такой ситуации. Ты сам тут много рассказывал, что вне конкретной задачи рассуждать об эффективности нельзя. И тут же предлагаешь мне что то рассказать про крайне общую ситуацию. Это, батенька, не совсем корректные приемчики, однако.
Я же приводил в пример оффлайн-клиент RSDN. Какой конкретики тебе не хватает?
НС> H>Когда задача решается несколькими инструментами с допустимой эффективностью.
НС> Что такое "допустимая эффективность"?
Когда ты укладываешься в сроки, бюджет и удовлетворяешь эндюзера.
Здравствуйте, Dzirt2005, Вы писали:
D>Здравствуйте, Abalak, Вы писали:
A>>По косвенным цифрам и наблюдениям, я же сказал. Или те тысяци вакансий на шарпе ни о чем не говорят? D>На самом деле они могут говорить об очень большой текучести кадров в выбранной области. Т.е. сальдо может быть даже отрицательным И да — количество вакансий очень слабо связано с качеством того, к чему эти вакансии относятся.
И чем в этом дотнет отличается к примеру от плюсов и джавы? Круто конечно о текучке и качестве судить по технологии.
Здравствуйте, hattab, Вы писали:
НС>> Для этого у нас к оценке привлекаются эксперты.
H>И сколько экспертов советовали тебе писать парсер на питоне?
Достаточно. Какая разница — сколько?
НС>> При чем тут профиль? В профиль пишут просто чтобы другим обри совать свой круг максимальной компетенции.
H>Человек себя позиционирует, как X-разработчик. Это и есть приверженность инструменту X.
Нет, не есть. Это, в общем случае, всего лишь констатация факта о наличии опыта.
НС>> Какое это имеет отношение к эффективности разработки? Или, по твоему, инструменты разработчика, которые мы тут обсуждаем, предназначены для решения "задачи эндюзера"?
H>Нет блин, они предназначены для того, чтоб ыксперты могли их советовать программистам Задача эндюзера это самое важное. В конце концов программисты для эндюзера, а не эндюзер для программистов.
Перечитай вопрос.
H>Я же приводил в пример оффлайн-клиент RSDN.
Негодный пример. Приложение некомерческое, написано ради интереса. Т.е. использование конкретной платформы в нем самоценно.
НС>> Что такое "допустимая эффективность"?
H>Когда ты укладываешься в сроки, бюджет и удовлетворяешь эндюзера.
Т.е., даже если использование привычного языка А в итоге приведет в удвоению сроков, нежели непривычного В, но при этом укладывается в заданные рамки, то будем использовать А, так?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>И сколько экспертов советовали тебе писать парсер на питоне?
НС> Достаточно. Какая разница — сколько?
Вообще, я уже говорил, что парсер это не та задача на которой можно что-то демонстрировать. Вот у меня была необходимость написать SAX-парсер. На знакомой дельфе я его написал за 45 минут (специально на время внимание обратил т.к. очень долго не хотел писать свой, а была идея взять сторонний). Если бы я выслушал экспертов, а потом изучал новый инструмент, я увеличил бы это время не просто вдвое, я увеличил бы его в разы/десятки раз и не факт, что решение было бы эффективным с точки зрения предъявляемых к нему требований.
НС> H>Человек себя позиционирует, как X-разработчик. Это и есть приверженность инструменту X.
НС> Нет, не есть. Это, в общем случае, всего лишь констатация факта о наличии опыта.
И откуда же тогда беруться мегасрачи между приверженцами, как бы не существующих, лагерей?
НС> НС>> Какое это имеет отношение к эффективности разработки? Или, по твоему, инструменты разработчика, которые мы тут обсуждаем, предназначены для решения "задачи эндюзера"?
НС> H>Нет блин, они предназначены для того, чтоб ыксперты могли их советовать программистам Задача эндюзера это самое важное. В конце концов программисты для эндюзера, а не эндюзер для программистов.
НС> Перечитай вопрос.
Перечитай ответ.
НС> H>Я же приводил в пример оффлайн-клиент RSDN.
НС> Негодный пример. Приложение некомерческое, написано ради интереса. Т.е. использование конкретной платформы в нем самоценно.
Для иллюстрации требуемого гуя более чем годный
НС> H>Когда ты укладываешься в сроки, бюджет и удовлетворяешь эндюзера.
НС> Т.е., даже если использование привычного языка А в итоге приведет в удвоению сроков, нежели непривычного В, но при этом укладывается в заданные рамки, то будем использовать А, так?
Меня больше интересует, откуда на этапе выбора инструмента у тебя возьмется информация об удвоения сроков. Снова мифические эксперты?
Здравствуйте, hattab, Вы писали:
H>Вообще, я уже говорил, что парсер это не та задача на которой можно что-то демонстрировать.
Там не просто парсер был, там была система сбора фидбека и публикации его в траке. Объем далеко не 45 минут.
НС>> Нет, не есть. Это, в общем случае, всего лишь констатация факта о наличии опыта. H>И откуда же тогда беруться мегасрачи между приверженцами, как бы не существующих, лагерей?
От фанатиков и берутся. Я ж тебе с самого начала говорил — все это в основном любителей таких срачей и интересует.
НС>> Т.е., даже если использование привычного языка А в итоге приведет в удвоению сроков, нежели непривычного В, но при этом укладывается в заданные рамки, то будем использовать А, так?
H>Меня больше интересует
Ты на вопрос сперва ответь.
H>, откуда на этапе выбора инструмента у тебя возьмется информация об удвоения сроков. Снова мифические эксперты?
Эксперты. Не мифические, а реальные. Экспертная оценка это довольно часто используемый, и часто единственный инструмент оценки. Очень странно, что он у тебя такие эмоции вызывает.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>И откуда же тогда беруться мегасрачи между приверженцами, как бы не существующих, лагерей?
НС> От фанатиков и берутся. Я ж тебе с самого начала говорил — все это в основном любителей таких срачей и интересует.
Назвать всех фанатиками много ума не надо. Однако, следует понимать, что если человек на PHP одинаково эффективно может решать задачи решаемые на ASP.NET, ему нет смысла менять освоенный инструмент на неизвестно что.
НС> НС>> Т.е., даже если использование привычного языка А в итоге приведет в удвоению сроков, нежели непривычного В, но при этом укладывается в заданные рамки, то будем использовать А, так?
НС> H>Меня больше интересует
НС> Ты на вопрос сперва ответь.
Ок. Отвечу в твоем стиле: я гарантирую, что используя знакомый инструмент решу задачу вдвое раньше означенных сроков, а ты взяв незнакомый инструмент завалишь проект
НС> Эксперты.
Все с тобой понятно. Как удобно. Вот у нас железобетонное мнение эксперта и на него мы будем ссылаться. Поди, поспорь
НС> Не мифические, а реальные. Экспертная оценка это довольно часто используемый, и часто единственный инструмент оценки. Очень странно, что он у тебя такие эмоции вызывает.
А если тебе эксперт посоветует кроличью лапку повесить на монитор, для повышения эффективности, повесишь? Каким, блин, образом некий эксперт определит, что вот эта задача на каком нибудь Qt будет решена эффективнее, нежели на каком нибудь WinForms, а твоя команда будет в состоянии освоить этот Qt? Что, дотнетчики-шарписты полезут изучать С++ и бороздить просторы большого театра внутренности Qt? Хотя я знаю, эксперт, разумеется, не скажет, что Qt будет эффективнее, глупость-то какая
Здравствуйте, hattab, Вы писали:
НС>> От фанатиков и берутся. Я ж тебе с самого начала говорил — все это в основном любителей таких срачей и интересует.
H>Назвать всех фанатиками много ума не надо.
Зачем всех? Только тех, кто бьется на форумах до последнего в защиту любимого языка.
H> Однако, следует понимать, что если человек на PHP одинаково эффективно может решать задачи решаемые на ASP.NET, ему нет смысла менять освоенный инструмент на неизвестно что.
Пока не появится задача, которую нельзя столь же эффективно решить на РНР.
НС>> НС>> Т.е., даже если использование привычного языка А в итоге приведет в удвоению сроков, нежели непривычного В, но при этом укладывается в заданные рамки, то будем использовать А, так? НС>> H>Меня больше интересует НС>> Ты на вопрос сперва ответь. H>Ок. Отвечу в твоем стиле: я гарантирую, что используя знакомый инструмент решу задачу вдвое раньше означенных сроков, а ты взяв незнакомый инструмент завалишь проект
Ты ошибся. Еще ни разу по этой причине не заваливал. И на вопрос ты так и не ответил.
НС>> Эксперты. H>Все с тобой понятно. Как удобно. Вот у нас железобетонное мнение эксперта
Нет, не железобетонное. И не одного эксперта, кстати. И не просто мнение, а обоснованное мнение. Т.е. не просто "Х крут", а "Х предпочтительнее, потому что ...". И обоснованное, кстати, без передергиваний и демагогий, в отличие от любимых тобой форумных флеймов.
H> и на него мы будем ссылаться. Поди, поспорь
А с чем ты спорить собрался вообще? Экспер делает оценку в конкретном случае, а не вообще. Или ты уверен, что ты прав, говоря что во всех моих случаях те эксперты, которые рекомендовали смену средства разработки, они неправы были? Ты конкретизируй — с чем ты поспорить хочешь, может и эксперты не понадобятся.
H>А если тебе эксперт посоветует кроличью лапку повесить на монитор
Не посоветует. Под экспертами я не форумных "экспертов" имею в виду, а людей, действительно компетентных и обладающих солидным опытом в области экспертизы, делающих экспертизу за деньги, и отвечающих за свои слова.
H>Каким, блин, образом некий эксперт определит, что вот эта задача на каком нибудь Qt будет решена эффективнее, нежели на каком нибудь WinForms, а твоя команда будет в состоянии освоить этот Qt?
А кто должен определять? Неужели низовые разработчики (лиды как правило в экспертную команду входят)?
H> Что, дотнетчики-шарписты полезут изучать С++ и бороздить просторы большого театра внутренности Qt?
Полезут, если это оправдано будет. Не считай других идиотами.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Назвать всех фанатиками много ума не надо.
НС> Зачем всех? Только тех, кто бьется на форумах до последнего в защиту любимого языка.
То есть лагеря таки есть. Уже хорошо.
НС> H> Однако, следует понимать, что если человек на PHP одинаково эффективно может решать задачи решаемые на ASP.NET, ему нет смысла менять освоенный инструмент на неизвестно что.
НС> Пока не появится задача, которую нельзя столь же эффективно решить на РНР.
А с этим я вообще не спорил, изначально указав на прочие равные, которые ты упорно делаешь вид что не понимаешь.
НС> H>Ок. Отвечу в твоем стиле: я гарантирую, что используя знакомый инструмент решу задачу вдвое раньше означенных сроков, а ты взяв незнакомый инструмент завалишь проект
НС> Ты ошибся. Еще ни разу по этой причине не заваливал. И на вопрос ты так и не ответил.
Тебе повезло. Везет не всем и не всегда. Неоднократно наблюдал накрывшиеся тазиком проекты из-за смены инструментария. Самый яркий пример, когда под задачу автоматизации нефтянки бывшие плюсисты пересаживались на жабу (не абы как, а тоже с экспертными мнениями, аналитиками). Закупили дорогущее оборудование, несколько мейнфреймов. В результате все сроки просрали, проект не дорос даже до минимальной степени готовности. Мейнфреймы остались пылиться на складе. А на вопрос я ответил. В твоем стиле.
НС> H>Все с тобой понятно. Как удобно. Вот у нас железобетонное мнение эксперта
НС> Нет, не железобетонное. И не одного эксперта, кстати. И не просто мнение, а обоснованное мнение. Т.е. не просто "Х крут", а "Х предпочтительнее, потому что ...". И обоснованное, кстати, без передергиваний и демагогий, в отличие от любимых тобой форумных флеймов.
Ок. Вот у нас мнение команды. И не просто мнение, а обоснованное мнение. И не потому, что "X" говно, а потому что на его изучение нужно N времени, плюс набивание шишек новыми граблями, и вероятность "потерять" проект не нулевая.
НС> А с чем ты спорить собрался вообще? Экспер делает оценку в конкретном случае, а не вообще. Или ты уверен, что ты прав, говоря что во всех моих случаях те эксперты, которые рекомендовали смену средства разработки, они неправы были? Ты конкретизируй — с чем ты поспорить хочешь, может и эксперты не понадобятся.
О, как интересно. Оказывается нам нужен конкретный случай! А я очем говорил, когда сказал, что без конкретики рассуждать об эффективности вообще смысла нет? Я сразу сказал о прочих равных, но ты начинаешь выдумывать какие-то невероятные удвоения сроков Откуда, при использовании равнозначного инструмента, да еще и знакомого команде, может взяться удвоение сроков?
НС> H>Каким, блин, образом некий эксперт определит, что вот эта задача на каком нибудь Qt будет решена эффективнее, нежели на каком нибудь WinForms, а твоя команда будет в состоянии освоить этот Qt?
НС> А кто должен определять? Неужели низовые разработчики (лиды как правило в экспертную команду входят)?
Почему низовые? Лиды и определяют, учитывая мнение, опыт и интересы команды. Только как лид определит, что незнакомый инструмент позволит ему более эффективно выполнить задачу? Как он может быть уверен, что половина команды не снимется и не уйдет на другой проект?
НС> H> Что, дотнетчики-шарписты полезут изучать С++ и бороздить просторы большого театра внутренности Qt?
НС> Полезут, если это оправдано будет. Не считай других идиотами.
Угу. Верится с трудом. Вот прям отбоя нет от станочников широкого профиля
Здравствуйте, hattab, Вы писали:
H>Тебе повезло. Везет не всем и не всегда. Неоднократно наблюдал накрывшиеся тазиком проекты из-за смены инструментария. Самый яркий пример, когда под задачу автоматизации нефтянки бывшие плюсисты пересаживались на жабу (не абы как, а тоже с экспертными мнениями, аналитиками). Закупили дорогущее оборудование, несколько мейнфреймов. В результате все сроки просрали, проект не дорос даже до минимальной степени готовности. Мейнфреймы остались пылиться на складе.
Осталось доказать, что это из-за смены инструментария.
H> А на вопрос я ответил. В твоем стиле.
Нет. Нет.
H>Ок. Вот у нас мнение команды. И не просто мнение, а обоснованное мнение. И не потому, что "X" говно, а потому что на его изучение нужно N времени, плюс набивание шишек новыми граблями, и вероятность "потерять" проект не нулевая.
Ну и? Ты почему то упорно пытаешься доказать мне, что нужно учитывать опыт команды. Да, нужно, вне всяких сомнений. Вот только это лишь один из факторов. И совсем не обязательно главный.
H>О, как интересно. Оказывается нам нужен конкретный случай!
Э нет, это тебе он нужен. Я всего лишь обратил твое внимание на то, что спорить с экспертом, чего ты хочешь, можно только при обсуждении конкретного случая. Которого нет. Соотв. и притензии твои неактуальны.
H> Только как лид определит, что незнакомый инструмент позволит ему более эффективно выполнить задачу?
У нормальных лидов кругозор несколько побольше одного единственного языка. И плюсы и минусы большей части мейнстрима они обычно представляют. В отличие от форумных пустозвонов.
H> Как он может быть уверен, что половина команды не снимется и не уйдет на другой проект?
О как. Вообще то для разработчика возможность за чужой счет новый язык это скорее плюс, нежели минус. Ты меня все больше удивляешь своим подходом.
НС>> Полезут, если это оправдано будет. Не считай других идиотами. H>Угу. Верится с трудом.
Это не вопрос твоей веры. Это легко наблюдаемый во многих компаниях факт.
H> Вот прям отбоя нет от станочников широкого профиля
При чем тут широкий профиль Для тебя переход под крупный проект с дотнета на джаву, к примеру, это широкий профиль? Однако, я даже и не знаю, что тебе на это сказать. Ты, я так понимаю, с начала профессиональной деятельности и по сю пору используешь исключительно Дельфи? Или все таки нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Тебе повезло. Везет не всем и не всегда. Неоднократно наблюдал накрывшиеся тазиком проекты из-за смены инструментария. Самый яркий пример, когда под задачу автоматизации нефтянки бывшие плюсисты пересаживались на жабу (не абы как, а тоже с экспертными мнениями, аналитиками). Закупили дорогущее оборудование, несколько мейнфреймов. В результате все сроки просрали, проект не дорос даже до минимальной степени готовности. Мейнфреймы остались пылиться на складе.
НС> Осталось доказать, что это из-за смены инструментария.
А других факторов небыло. До того случая у них проблем не наблюдалось.
НС> H>Ок. Вот у нас мнение команды. И не просто мнение, а обоснованное мнение. И не потому, что "X" говно, а потому что на его изучение нужно N времени, плюс набивание шишек новыми граблями, и вероятность "потерять" проект не нулевая.
НС> Ну и? Ты почему то упорно пытаешься доказать мне, что нужно учитывать опыт команды. Да, нужно, вне всяких сомнений. Вот только это лишь один из факторов. И совсем не обязательно главный.
А кто говорил, что он главный? Я сказал, что он решающий при прочих равных.
НС> Э нет, это тебе он нужен. Я всего лишь обратил твое внимание на то, что спорить с экспертом, чего ты хочешь, можно только при обсуждении конкретного случая. Которого нет. Соотв. и притензии твои неактуальны.
Чудеса да и только. Сперва ты заявляешь о каком-то удвоении сроков для знакомого и равнозначного другому инструмента. Теперь оказывается у меня какие-то претензии... Да я, собственно, только и хочу узнать откуда вот такое экспертное мнение возьмется
НС> H> Только как лид определит, что незнакомый инструмент позволит ему более эффективно выполнить задачу?
НС> У нормальных лидов кругозор несколько побольше одного единственного языка. И плюсы и минусы большей части мейнстрима они обычно представляют. В отличие от форумных пустозвонов.
А-а-а, тимлид мегамозг. Я понял. Желал бы я увидеть человека действительно разбирающегося в мейнстримовых инструментах, скажем, гуестроения. Разбирающегося настолько, чтоб он мог адекватно оценить эффективность, а не проехавшегося по вершкам и думающего, что он просвещен
НС> H> Как он может быть уверен, что половина команды не снимется и не уйдет на другой проект?
НС> О как. Вообще то для разработчика возможность за чужой счет новый язык это скорее плюс, нежели минус. Ты меня все больше удивляешь своим подходом.
Если это замена шила на мыло, то смысла и правда мало
НС> H> Вот прям отбоя нет от станочников широкого профиля
НС> При чем тут широкий профиль Для тебя переход под крупный проект с дотнета на джаву, к примеру, это широкий профиль?
Нет. Близкие технологии.
НС> Однако, я даже и не знаю, что тебе на это сказать. Ты, я так понимаю, с начала профессиональной деятельности и по сю пору используешь исключительно Дельфи? Или все таки нет?
Нет. Дельфя далеко не первый инструмент и не последний, и даже не любимый, если ты к этому клонишь.
Здравствуйте, Abalak, Вы писали:
A>Здравствуйте, Dzirt2005, Вы писали:
D>>Здравствуйте, Abalak, Вы писали: A>> Боюсь их не существует в природе. По косвенным признакам и собственным наблюдениям, жаба заделывает дотнет в энтерпрайзе, но не сильно, думаю 60/40 среди них двоих.
A>>>По косвенным цифрам и наблюдениям, я же сказал. Или те тысяци вакансий на шарпе ни о чем не говорят? D>>На самом деле они могут говорить об очень большой текучести кадров в выбранной области. Т.е. сальдо может быть даже отрицательным И да — количество вакансий очень слабо связано с качеством того, к чему эти вакансии относятся.
A>И чем в этом дотнет отличается к примеру от плюсов и джавы? Круто конечно о текучке и качестве судить по технологии.
Абсолютно ничем. Мое сообщение касалось того, что "Или те тысяци вакансий на шарпе ни о чем не говорят?" — именно что в общем случае не говорят абсолютно ни о чем, т.е. по количеству вакансий абсолютно нельзя судить о том, что кто-то заделывает кого-то (или что кто-то качественнее кого-то).
)? Рассуждать об эффективности инструмента в отрыве от опыта использования это вообще смешно.
А рассуждать об эффективности без конкретики, это уже демагогия. Опять же эффективность она какая? Эффективность разработчика использующего инструмент (а она целиком и полностью зависит от опыта), или же эффективность решения созданного с помощью инструмента (но всегда есть пределы допустимого)? Но как бы там ни было, при определении критериев, сильно сомнительно получить, в результате, один единственный инструмент.
