На днях рефлексировал свой и индустриальный опыт внедрения DDD (BDD, Pair Programming, допишите свое). Выводы не утешительны: почти всегда, а особенно при давлении сроков, легаси, окружения разработчик выберет то что привычно. Как говорил Макс Дорофеев:

наша обезьянка между важным и срочным выбирает... Простое и понятное!

Так и в разработке (и любой другой деятельности) все новое и непонятное отторгается.
Новое требует больше энергозатрат твоего мозга!
Новое снижает твою экспертность, только что ты был синьором, а тут какой-то агрегат надо выделить!
Новое опасно, вдруг сроки поедут и начальник заругает.

И если это так страшно и затратно, то зачем? Не жили богато, нечего начинать.

Что же делать? Искать единомышленников!

Если вы руководитель, то путь простой - нанимать и растить тех кто ценит рост, всячески поощрять такое поведение в рамках своих полномочий, оставлять разработчикам "воздух" на рискованные затеи. Ну и не забывать про доверие и психологическую безопасность.

Если вы обычный гребец разработчик, то все сложнее, но вот что можно попробовать:

1. Рассказывайте! На кухне, в слаке, на внутренних митапах, на больших конференциях. Подкидывайте твиты, видеоролики. Возможно в компании есть единомышленники, но вы друг про друга даже не знаете.
2. Если у вас принято приглашать на внутренние митапы внешних экспертов, то попробуйте сами договориться с кем-то кто продвигает нужную вам повестку. Люди доверяют внешним экспертам.
3. Если в компании используется нужная вам практика, но не в вашей, а в других командах, можно договориться об интро или даже о полноценном погружении внутри той команды или позвать к себе представителя команды.
4. Договоритесь о небольших экспериментах внутри команды, если тиммейты вас поддержат – можно будет регулярно практиковать на живых задачах, набирать уверенности, экспертности, кейсов для демонстрации профита и прочего.

Поделитесь вашим опытом – что сработало, а что оказалось бесполезным?