Дело в том, что попробуйте продать людям не обязательный кодревью, скажите, теперь у нас нет обязательного кодревью и кто хочет тот может просить чтобы его ревьювили и попробуйте доказать людям, что это эффективно. Люди не дураки, они быстро поймут эффективно или нет.

Бороды

А какой вред приносит блокирующее код ревью, я так и не сумел понять?

Погодите, ток внедрили (добровольно), еще рано вынидрять

Рвет непрерывный процесс разработки

Кодревью? Добровольно? Типа если человек не просит, то вы без ревью разрешаете ему в мастер мерджить?

Ну да, бывает договариваемся, что не нужно. Но пока есть польза

У меня это было как.  Был старый код который настолько хорошо был разработан и спроектирован чио его 2 года никто не трогал работает и работает. А нут понадобилось его ускорить в 10 раз. Сразу двум инженерам была поставлена задача - разобраться и придумать. Сначала они поодиночке пытались потом один стоял за спиной второй кодил проверял гипотезы.  А потом стали клавиатуру вырывать друг у друга. Потом вместезапроектировали изменения и стали кодить какие то куски у себя на местах какие то в основном интегрировать вместе. Но так дальше и остальное пошло в таком же макаре разрабатываться

Тот что блокирует

Если до код ревью пролезают блокирующие проблемы их чинить надо на более ранних этапах процесса, а не когда уже все написано

Тогда откуда цифра 20% потери эффективности? Если мы используем 100% одного инженера и 100% другого, то мы теряем 100% эффективности на задачу. Кроме случаев, когда условное time to QA, или какое у нас следующее узкое место, не ускоряется кратно, тогда потери меньше. Чтобы они составили суммарно 20%, надо, чтобы ускорение у обоих было 40%. Выходит, парным программированием задачи решаются почти вдвое быстрее, чем одиночным?

а как вы без машины времени это помереяте? вот если бы они по отдельности решали эту задачу то было бы...

Люди почти весь день работают, пришли сели и работают, в чатах не переписываются, чай пьют синхронно за компом, обедают вместе и т.п.

а все задачи - как ни странно - разные

Ну да потому что фазы и проектирования и кодинга и ревью у вас объединены. Оба разработчика в контексте задачи

Задачи разные, а время на все задачи примерно одинаковое

Да еще нет выподания из потока они не ходят не отвлекают друг друга «а посмотри мой код» не ревьювят не правят после ревью. Задачи не зависают в фазе ожидания ревью. Не мержат конфликты

примерно - да. но на какойто конкретной задаче - эффективность "парного" подхода может давать +100500, а на другой - такой же минус

Я не могу представить такую задачу

Ну если вы только гуй какойнить делаете, везде где можно кодить или ченить такое делать, везде эффективнее, даже серваки настраивать быстрее, сам будешь чёт руками делать, а так заскриптовали и поставили роботов делать