Да, внутри компании есть разные заказчики. Внешних я могу фильтровать или наценку "за вредность" делать, а внутри такой подход не поймут :)

Полностью согласен

Меня крайне смущает концепция anything-as-a-code - это звучит как влажная мечта разработчиков избавиться от других людей в разработке. Особенно от бизнеса)

У меня складывается ощущение, что те, кто говорят, что управление требованиями фактически не нужно и достаточно примерного "описания", имхо, не сталкивались с действительно крупными проектами, особенно - долгосрочными. В общем, весь кровавый в это время плачет кровавыми своими слезами.
Требование к системе - это не придаток к коду. Это код - придаток к требованию. Нечто, что его может реализовать (а может и не код, а что-то еще). А требование - это приспособа к потребности стейкхолдера, которому от системы что-то надо. Код ему нахрен не нужен.

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

комментарии часто out-of-sync с кодом, а код сам по себе не врет - делает что написано
требования - архиважны и тут полностью солидарен. Особенно в крупных проектах

комментарии нужны для public API

если генерим автоматом доки

Код не врет, но дофига не договаривает, к сожалению. И говорит на специфическом языке.

20 лет разрабатываю софт и всегда смотрю в код. Код мне скажет все, а что не скажет - вытяну из бинарников :)

Вопрос трудозатрат. Мой нынешний проект был принят у другого подрядчика. Регулярно разрабы воют от того, чтобы выяснить, что происходит в коде. Доходит до того, что сидят за компом двое - аналитик и разработчик, в попытках понять, что же значит написанное (с какими объектами, какие проверки, какая логика...). Очень долго.

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

sourcegraph поставте

А особенно если за разрабами не было контроля - ревью и архитектурного.

может помочь с анализом зависимостей

Да :(

любопытно, спс

главное при анализе кода goto definition / find refrences
для Java Eclipse-а хватает. Там можно и плагин  самому набрость для вытаскивания деталей
с С++ сложней, надо продукты Klocwork-а
для Go и т.п и так уже много, в том числе тот же sourcegraph

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

c динамическими языками хуже из-за отсуствия типизации