Представьте себе, что вы идёте по цветущему ромашковому лугу и внезапно утыкаетесь в забор. Просто забор, без ограды и чего-либо ещё. «Что за ерунда?» — скорее всего, первым делом подумаете вы.
Наверняка у вас возникнут мысли, что забору здесь не место и вообще было бы неплохо его снести. Но это решение плохое, потому что вы не знаете назначения забора. Этот принцип обычно связывают с Гилбертом Честертоном: не ломайте забор, пока не поняли, зачем его поставили.
Аналогия с забором хорошо показывает, как мы можем заблуждаться в своих убеждениях. Частенько специалист приходит в новую команду и такой “а чего это у вас тут всё так плохо сделано, ща поправим”. Невелика беда, если этим занимаются программисты - их на код ревью завернут и объяснят. Но ситуация становится гораздо веселее, когда принцип забора Честерсона начинают нарушать тимлиды и руководители выше.
Не все команды успели построить устойчивые системы, а часто вообще всё держится на костыльных процессах и взаимовыручке. Поэтому изменение даже незначительной на первый взгляд детали (того самого забора) может привести к нарушению всего процесса и коллапсу.
Внесение изменений без понимания ситуации может принести руководителю и его команде кучу неприятностей. Да, можно понять энтузиазм руководителя - он вышел на новое место и хочет как можно быстрее показать себя с лучшей стороны. Но если вы начинаете работать в новых условиях, то сначала лучше будет собрать как можно больше информации и разобраться в том, как сейчас всё устроено. Иначе будет ситуация как в той байке, где программисты “Войну и мир” поддерживали.