[Перевод] Разработка ПО через призму эксперимента Милгрэма «Подчинение авторитету»
На прошлой неделе я потратил прилично времени удаляя мёртвый код из нашей кодовой базы. Я люблю удалять код. Как по мне, так мало вещей приносят такое же удовольствие, как наведение порядка в коде. Да я настолько люблю это делать, что меня вызывают недоумение инженеры, которые оставляют ненужный код в приложении. Но на выходных я услышал, как кто-то разговаривал об эксперименте Милгрэма «Подчинение авторитету» (на хабре также писали об этом — прим. переводчика) и я не смог не провести параллели между человеком, который бил током другое человеческое существо и инженером, который оставляет заведомо известные баги и плохой код.
Если вы не знакомы с экспериментом Стэнли Милгрэма, то он заключается в том, что Экспериментатор (человек, наделённый властью) приказывает Учителю (объект исследования) бить серией увеличивающихся разрядов тока Ученика, который находится в другой комнате. Иллюстрация из википедии:
E — экспериментатор (experimenter), T — учитель (teacher), L — ученик (learner)
Суть эксперимента заключалась в изучении реакции людей на приказы, которые вступают в конфликт с их моральными принципами. До проведения эксперимента считалось, что большинство испытуемых прекратят эксперимент как только поймут, что причиняют Ученику боль. Однако во время проведения эксперимента выяснилось, что поразительное количество испытуемых доходили до максимального разряда в 450 вольт.
В первом наборе экспериментов Милгрэма 65 процентов участников (26 человек из 40) использовали максимальное возможное значение в 450 вольт, хотя им было и неприятно делать это; в определённый момент времени каждый участник останавливался и сомневался в эксперименте; некоторые участники хотели прекратить и вернуть деньги, которые им заплатили за участие. В течении эксперимента у участников наблюдались различные степени волнения и стресса. Они потели, дрожали, заикались, кусали губы, стонали, впивались ногтями в кожу, некоторые нервно смеялись.
Когда мы узнаём о таких результатах, то нам хочется верить, что мы бы так никогда не поступили. Нам хочется верить, что «просто подчинение приказам» — это человеческий недостаток, которого у нас нет. Но эксперименты, типа эксперимента Милгрэма показывают, что такая вера в лучшем случае оптимистична, а в худшем — полностью не верна.
И теперь, когда мы знаем как люди реагируют на авторитет, когда на кону физическая боль давайте посмотрим как программисты реагируют на авторитет, когда речь идёт о более абстрактных вещах, таких, как фрустрация и неудобство. Давайте возьмём диаграмму эксперимента Милгэма и переделаем её так, чтобы она отражала команду разработки:
Если мы посмотрим на команду разработки так, как это изображено на иллюстрации, то уже не так удивляет почему мы, инженеры, оставляем плохой код и оставляем известные баги. Вероятно в какой-то момент человек, обладающий властью ясно дал понять, что у нас нет времени исправлять проблемы или эти проблемы недостаточно приоритетны по сравнению с другими вещами в роадмапе. Или что удаление мертвого кода не приносит ценности пользователю. В итоге оставляем код как есть и переходим к следующей задаче, хотя это вступает в конфликт с нашим моральным компасом и понятиями о том, что такое хорошо, а что такое плохо.
В эксперименте Милгрэма испытуемые часто колебались и протестовали против того, что послать очередной разряд человеку в другой комнате. В таких случаях экспериментатор требовал продолжения одной из предопределённых фраз:
- «Пожалуйста, продолжайте» (Please continue/Please go on);
- «Эксперимент требует, чтобы вы продолжили» (Experiment requires that you continue);
- «Абсолютно необходимо, чтобы вы продолжили» (It is absolutely essential that you continue);
- «У вас нет другого выбора, вы должны продолжать» (You have no other choice, you must go on).
Не используя ничего, кроме слов экспериментатор смог добиться того, что 65 процентов испытуемых против своей воли били очень болезненными разрядами тока других людей. Интересно, какие слова мы используем в контексте разработки программного обеспечения?
- Это не мы решаем, а команда продукта
- Нам нужно уложиться в дедлайн
- Команда маркетинга собирается выпустить пресс-релиз на следующей неделе
- Мы закрываем слишком мало тикетов
- Мы все равно потом выкинем этот код
- Это временное решение
- Нужно улучшить производительность твоей команды
- Это затронет небольшое количество пользователей
- Это не приоритетно для нас сейчас
- Мы починим это потом
- Этого хочет руководство
- Почему так долго?
- Нужно быстрее сделать это
Я пишу об этом не для того, чтобы предложить какое-то решение. У меня его нет. Я пишу для того, чтобы взрастить — прежде всего в себе — сочувствие и понимание. Когда я вижу код, который оставляет чувство недоумения или поведение, которое я не понимаю я должен помнить, что действия не всегда отражают намерения. Я должен помнить, что инженеры оставляют плохой код не потому, что им всё равно — они оставляют плохой код потому, что у них не было свободы привести его в порядок. И они оставляют баги не потому, что им плевать на пользователей, а потому, что у них не было полномочий отклоняться от роадмапа продукта.
