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

Добавлю одну главу по обсуждаемой теме из довольно интересной на мой взгляд книги Факты и заблуждения профессионального программирования (c) Роберт Гласс :

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

Обсуждение
Изучение нового инструмента или метода — дело хорошее, если его применение сулит выгоду. Но, пожалуй, не настолько хорошее, как нас уверяют те, кто первыми бросаются применять новые идеи и технологии. За умение применять новые идеи приходится платить. Новую идею надо понять, посмотреть, подходит ли она для работы, решить, как ее применить, и продумать, когда имеет смысл ее применять, а когда нет. Когда нас заставляют задумываться над рабогой, которую до этого мы делали автоматически, мы начинаем работать медленнее.
Какова бы ни была новая идея — взять на вооружение средство анализа тестового покрытия и понять, что это означает для процесса тестирования, или испытать технологию экстремального программирования и приспособиться ко всем его методам, — тот, кто будет ее осваивать, станет работать медленнее и не так эффективно, как прежде. Это не означает, что новых идей нужно избегать, это всего лишь означает, что первый проект, в котором они будут применяться, будет продвигаться медленнее, чем обычно (а не быстрее).
Последние пару десятков лет улучшение производительности и качества продукта было Святым Граалем процесса программирования. Мы берем на вооружение новые инструменты и методы, потому что хотим улучшить продуктивность и качество. Ирония перехода к другой технологии заключается в том, что продуктивность и качество сначала, когда мы "переключаем передачи" и пробуем что-то новое, падают, а не растут.
Но волноваться тут не о чем. Если новинка действительно полезна, то в конечном итоге это станет явным. Правда, возникает вопрос: "Как скоро?"
То, о чем мы говорим, есть кривая обучения (learning curve). На кривой обучения эффективность вначале падает, потом поднимается, проходя через обычное значение, и выходит на плато, соответствующее выигрышу от нововведения. Все это превращает один вопрос "как скоро" в несколько таких вопросов. Как долго мы будем иметь заниженные показатели? Как скоро мы вернемся к их обычным значениям? Как скоро мы получим конечный выигрыш?
Каждый из нас хотел бы иметь возможность ответить что-нибудь вроде "три месяца" или "шесть месяцев". Но, конечно, по этому поводу никто не может сказать ни этого, ни чего-либо еще. Длина кривой обучения зависит от ситуации и обстановки. Как правило, чем больше выигрыш в конце, тем длиннее кривая обучения. Чтобы освоить объектно-ориентированный подход поверхностно, требуется три месяца, но чтобы стать специалистом, может потребоваться два года плотной работы. Для других методологий цифры могут быть совершенно другими. Единственное, что можно предсказать наверняка, — это наличие кривой обучения. Можно нарисовать кривую на графике, но невозможно осмысленно предложить масштаб для его осей.
Остается еще один вопрос: "Насколько?" Насколько прибыльной окажется новая идея? Это такая же неизвестная, как и ответ на вопрос "как скоро". Все хорошо, кроме одного. Судя по тому, что мы узнали из предыдущего факта, с наибольшей вероятностью отдача будет на 5-35% выше, чем до принятия на вооружение новой идеи.
Есть и еще одно важное обстоятельство. Мы не можем дать общие ответы на вопросы "как скоро" и "насколько", но ответы все-таки есть. О каком бы новшестве ни шла речь — об анализаторах тестового покрытия или экстремальном программировании, — эти ответы можно получить, обратившись к опытным специалистам. Отыщите (в локальной сети, в группах пользователей, в профессиональных сообществах и т.д.) тех, кто уже освоил то новое средство, которое вы хотите включить в свой арсенал, и поинтересуйтесь, сколько времени это потребовало (скорее всего они знают ответ на этот вопрос) и какую пользу это им принесло (это более серьезный вопрос, и, если они не пользуются метриками, они могут и не ответить). И не забудьте выяснить, чему они научились (все "за" и "против") в процессе освоения.
Само собой, надо держаться подальше от фанатиков. Их ответы чаще опираются на веру, а не на опыт.

Полемика
Полемики по данному поводу быть не должно. Очевидно, что изучение нового имеет свою цену. Но на практике, однако, нередки противоречия. Фанатики обещают быстрый процесс обучения и огромные преимущества, а менеджеры слишком часто начинают верить как в первое, так и во второе. Менеджеры ожидают, что эффективность новых подходов проявится, как только их начнут применять. Соответственно затраты и сроки оцениваются исходя из предположения, что выгоды будут получены с самого начала.
Как классический пример данного эффекта приводят некую фармацевтическую компанию, которая, осваивая пакет SAP, приняла невыгодные предложения по некоторым контрактам, т.к. рассчитывала на мгновенную отдачу от SAP. Когда закончился период освоения, компания погибла в огне банкротства и судебных исков. "Не пытайтесь повторить это самостоятельно!" — вот какой урок мог бы быть извлечен из этой истории.

Источник
Кривая обучения и ее влияние на развитие процесса описаны во многих книгах, включая данную:
Weinberg, Gerald. 1997. Quality Software Management: Anticipating Change. Vol. 4, pp. 13,20. New York: Dorset House.