ой да ладно.
можно подумать у вас на дестопе виндоуз 7/последняя убунта, кодите вы в последней версии IDE (ганимед/ZDE)?
выбор новой технологии должен быть обусловлен только преимуществами, которые она дает. Если преимущества сводятся к «новее» — это не довод убивать время на перенос проекта с одного на другое.
Про причины выбора можно посмотреть в комментариях.
Здесь же мы видим обобщения — работать с художниками в одном тиме народ не против (4/3), что не говорит практически ни о чем.
Но вот при жестком дедлайне никто (!) не хотел бы художником руководить.
И это именно то, с чем приходится сталкиваться IRL.
Потому что в критический момент может оказаться проще написать самому, чем долго спорить о преимуществах SVN перед CVS.
1. Вы — тимлид на фрилансе. Вам предложили сделать интернет-магазин, с очень сжатыми сроками (2 недели, скажем).
Вы можете взять в помощь двух программистов, кого вы выберете?
Знаете, я подумал что главный вопрос в том с какой стороны баррикад смотреть.
Давайте сделаем простой опросник. Я отпишу две ситуации, отдельно для тимлидов и отдельно для разработчиков. Вам я предлагаю плюсовать за тот вариант, который вам больше нравится.
Большая просьба не минусовать (иначе результат будет не точным) и не голосовать за оба варианта, т.е. Вы или программист или тимлид (как в жизни).
О! Это я и хотел услышать.
Теперь сравните эти ответы с вашими же словами выше:
1. Уход у другую компанию — неудача.
2-3. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
И еще раз говорю — это нормально. Это нормальный цикл развития продукта. И совсем не значит что те кто начинали продукт «таджики».
когда вы уходили из своих проектов, вы все их завершали?
Вы с самого начала вели проект больше двух лет? Ядро ни разу не переписывали?
Только при положительном ответе на все три вопроса имеет смысл что-то обсуждать. Вы берете ситуацию «если бы в тиме и в менеджменте были бы одни такие программисты как я».
у вас какие-то заказчики и менеджеры в вакууме. В моей практике случается по-другому.
>И получат по шапке за срыв сроков. А это не в интересах художников
Во-первых как получат? Лишат премии? Вы сами писали, художникам она не нужна. Поругают? Художник напишет пост зла о том как его не понимают и уйдет в другую фирму.
Во-вторых в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего.
>Этим должны заниматься тестеры.
Есть еще маленькие проекты, где тестеров, увы, нет.
>Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков
По моему опыту, когда проект активно меняется в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей. И это — нормально.
>Опыт работы во многих компаниях, в больших и малых командах
Недавно слышал как директор одной довольно крупной компании отклонил кандидатуру программиста, потому что у него в трудовой книжке не было ни одной работы продолжительностью больше года. По его мнению это говорит о том что или человек не уживается в коллективе или не усидчив, или что «свалит при первой же проблеме».
>1.Менеджмент, состоящий из IT-художников стремится выполнить любую задачу быстро, как только может.
Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
Не потому что старая была плоха, просто писать на старой — скучно!
>2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать.
А когда баги вдруг все-таки случаются художники очень-очень удивляются, ведь они творцы! Багов не допускают! А нормально протестировать проект — лень, потому что это же рутина.
Вместо этого лучше почитать про новый фреймворк, и пофиг что из-за этого одного бага проект заказчика навернулся и фирмы вылетела в копеечку. Творец уверен — в перспективе он принес бы большую прибыль.
3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо.
Очень удобно, придти на новое место, назвать всех «таджиками», себя «д'артаньяном» и предложить переписать проект с нуля. Это постоянное желание «творцов» — переписать с нуля.
Вот только заказчику нужно совсем не это, заказчику нужна скорость реакции. И это именно та причина, почему «таджики» пробиваются в руководство, а «творцы» нет.
P.S. Напомнило из Пелевина «Криейторы нам нафиг не нужны! Нам нужны творцы!».
Намедни был пост про всемирный конкурс по программированию, кто оказался в пятерке? Выпускники этого же института образования. Значит не все так плохо как вам кажется?
«Восстановление реального производства» как вы выразились уже нафиг не надо. Надо идти дальше и строить новое, не пытаясь удерживать старое.
Никогда не думали, почему ту же сталь продает Китай? У которого своих ресурсов практически нет?
можно подумать у вас на дестопе виндоуз 7/последняя убунта, кодите вы в последней версии IDE (ганимед/ZDE)?
выбор новой технологии должен быть обусловлен только преимуществами, которые она дает. Если преимущества сводятся к «новее» — это не довод убивать время на перенос проекта с одного на другое.
Здесь же мы видим обобщения — работать с художниками в одном тиме народ не против (4/3), что не говорит практически ни о чем.
Но вот при жестком дедлайне никто (!) не хотел бы художником руководить.
И это именно то, с чем приходится сталкиваться IRL.
Потому что в критический момент может оказаться проще написать самому, чем долго спорить о преимуществах SVN перед CVS.
Вы можете взять в помощь двух программистов, кого вы выберете?
Давайте сделаем простой опросник. Я отпишу две ситуации, отдельно для тимлидов и отдельно для разработчиков. Вам я предлагаю плюсовать за тот вариант, который вам больше нравится.
Большая просьба не минусовать (иначе результат будет не точным) и не голосовать за оба варианта, т.е. Вы или программист или тимлид (как в жизни).
Теперь сравните эти ответы с вашими же словами выше:
1. Уход у другую компанию — неудача.
2-3. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
И еще раз говорю — это нормально. Это нормальный цикл развития продукта. И совсем не значит что те кто начинали продукт «таджики».
Вы с самого начала вели проект больше двух лет? Ядро ни разу не переписывали?
Только при положительном ответе на все три вопроса имеет смысл что-то обсуждать. Вы берете ситуацию «если бы в тиме и в менеджменте были бы одни такие программисты как я».
>И получат по шапке за срыв сроков. А это не в интересах художников
Во-первых как получат? Лишат премии? Вы сами писали, художникам она не нужна. Поругают? Художник напишет пост зла о том как его не понимают и уйдет в другую фирму.
Во-вторых в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего.
>Этим должны заниматься тестеры.
Есть еще маленькие проекты, где тестеров, увы, нет.
>Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков
По моему опыту, когда проект активно меняется в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей. И это — нормально.
Недавно слышал как директор одной довольно крупной компании отклонил кандидатуру программиста, потому что у него в трудовой книжке не было ни одной работы продолжительностью больше года. По его мнению это говорит о том что или человек не уживается в коллективе или не усидчив, или что «свалит при первой же проблеме».
Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
Не потому что старая была плоха, просто писать на старой — скучно!
>2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать.
А когда баги вдруг все-таки случаются художники очень-очень удивляются, ведь они творцы! Багов не допускают! А нормально протестировать проект — лень, потому что это же рутина.
Вместо этого лучше почитать про новый фреймворк, и пофиг что из-за этого одного бага проект заказчика навернулся и фирмы вылетела в копеечку. Творец уверен — в перспективе он принес бы большую прибыль.
3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо.
Очень удобно, придти на новое место, назвать всех «таджиками», себя «д'артаньяном» и предложить переписать проект с нуля. Это постоянное желание «творцов» — переписать с нуля.
Вот только заказчику нужно совсем не это, заказчику нужна скорость реакции. И это именно та причина, почему «таджики» пробиваются в руководство, а «творцы» нет.
P.S. Напомнило из Пелевина «Криейторы нам нафиг не нужны! Нам нужны творцы!».
мы же говорим про уровень образования, а не про конкретных людей
«Восстановление реального производства» как вы выразились уже нафиг не надо. Надо идти дальше и строить новое, не пытаясь удерживать старое.
Никогда не думали, почему ту же сталь продает Китай? У которого своих ресурсов практически нет?
Ноут не роняли? Прохладительными/Горячительными напитаками не заливали?
Особенно радуют процессы типа servises.exe