Влияет ли техстек на эффективность разработки?

Я более 25 лет занимаюсь разработкой и за это время успел попробовать десяток разных языков программирования и еще десяток понаблюдал близко.

Возьмем, к примеру, такой довольно стандартный проект, как интернет-магазин и такую стандартную задачу - добавление платежной системы для оплаты покупателем. У нее есть стандартные этапы по внедрению:

Постановка задачи
Расписывание технического исполнения
Непосредственная реализация технического исполнения
Написание unit тестов
Code-review
Приемное тестирование задачи на staging(dev) сервере
Приемное тестирование задачи на production сервере

И по моим наблюдениям(на очень многих проектах и разной степени квалификации исполнителей), исполнение данного списка задач не сильно зависит от того, на каком техническом стэке и языке его выполняют, так как бизнес-логика по сути примерно одинакова. Ну то есть более сложные платформы типа Java добавят свои 20-30% ко времени реализации, но в целом картину сильно не меняют.

Более того, ни один подход к разработке - Agile, Scrum, XP, парное программирование, практически никак не сократят время на исполнение задачи.Как же добиться существенного сокращения времени исполнения задачи?Вот реально работающие методы, которые я лично наблюдал:

Сокращение шагов по внедрению. На самом деле, тесты и code review - первое, что может пойти под нож, если исполнитель достаточно квалифицирован и опытен. Тестирование задачи на production тоже некоторые компании исключают(юзеры - наши лучшие тестеры) и в некотором плане это действительно работает.
Упрощение самой задачи. Меньше функционала => меньше кодить => меньше тестировать => меньше вероятность ошибки. Казалось бы, простая логическая цепочка, но очень многие усложняют задачи без особых на то причин.
Задачу, по возможности, должен выполнять один человек. Даже простое разделение задачи на backend и frontend разработчиков может в разы увеличить время исполнения. А причины простые - разработчиков нужно синхронизировать по времени, часто будет перекладывание ответственности и недовольство, взаимное недопонимание(усложняемое удаленкой).
От всех разработчиков нужно добиваться ответственной разработки - чтобы весь код после передачи на приемное тестирование не содержал лишнего, был готов к production, а задача была достаточно протестирована непосредственно самим разработчиком. Часто наблюдал такую картину - разработчик, чтобы показать скорость, коммитит сырой код - не все корректно работает, видны небрежности и отладочные куски кода. Естественно, задача заворачивается обратно code-reviewer’ом или тестером-приемщиком. И так порой несколько раз. В итоге задача значительно растягивается по времени - недели или даже месяцы.
Более продуманная поставновка задачи и более тщательное описание технической реализации сильно экономят итерации «сделали - посмотрели - увидели, что не то - отдали на переделку».

В качестве вывода:

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