Это ложная дихотомия. Навязанный процесс не коррелирует с успехом. Например, в телефонных компаниях разработчики программного обеспечения навязывают огромное количество процессов (наивное чтение разработки «водопада»), в результате чего тратится много времени на написание подробных проектных документов, а затем, когда программное обеспечение неожиданно доставляется клиентам обнаружить, что они просили не то, что они хотели. В этот момент ресурсы почти исчерпаны, и все проигрывают. Навязанный процесс убивает проекты.
С другой стороны, когда Амитабх Шривастава наложил некоторые основные требования к анализу и тестированию для команды Windows, уровень ошибок снизился, и, по крайней мере, среди моих друзей в Microsoft, производительность и моральный дух повысились. Я предполагаю, что нечто подобное произошло в проекте KDE, когда они начали требовать от всех использования valgrind . Внезапно больше нет ошибок памяти и сбивает с толку дампы ядра.
В общем, я думаю, что более удачно навязать полезные инструменты , чем навязать процессы . Доказательства за или против полезности инструмента могут накапливаться довольно быстро. Единственный «процесс», который я видел, неизменно успешен - это то, что несколько пар глаз должны видеть код. Механизм, с помощью которого достигается этот просмотр, не имеет значения.
Свобода для разработчиков - это совсем другой вопрос. Мне повезло в том, что у меня есть работа, где у меня есть почти полная свобода выбирать все в моей среде разработки. (Пример: я работаю в магазине Red Hat, но у меня был бюджет на покупку компьютера и установку Debian.) Поскольку у меня более 20 лет непрерывного опыта разработки программного обеспечения, я обычно могу довольно неплохо выбирать, какие языки и инструменты использовать. использовать. Но обратной стороной этого является то, что я могу быть достаточно продуктивным на любом языке или в любой среде. Использование perl или C ++ может замедлить меня в 2 или 3 раза, а использование Lua или Haskell ускорит меня при определенных проблемах, но я доберусь до конца.
Но я работал с другими разработчиками, которые имеют очень ограниченную зону комфорта в отношении языков и инструментов, и которые с радостью выберут очень неправильный инструмент для своей работы, если им будет предоставлена свобода делать это. Однажды меня попросили как консультанта попытаться помочь группе ускорить компилятор, который собирал небольшие программы за 24 часа. Оказывается, что люди, которые написали это, были людьми из экспертной системы, и они написали компилятор, используя механизм логического вывода на основе правил. Они заставили его работать, но это была неправильная технология для работы.
Я также видел, что ограничение разработчика конкретной средой или языком не является гарантией успеха. Я считаю себя очень плохим программистом на Perl; Я в основном отношусь к perl как к awk на стероидах. Я полный идиот. И все же мне приходилось иметь дело с кодом на Perl, написанным другими, который был намного хуже всего, что я мог написать, просто потому, что они никогда не учились думать о проблемах или о том, как организовать код.
Думаю, мне лучше прекратить разглагольствовать сейчас.