Ну так кто мешает создать? Вперёд

Согласен. Но есть и другая сторона. Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством. Я в свое время писал на emacs, и многие мои друзья писали на emacs, и там по логу можно легко в этом убедиться.

Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система. А именно в этом и заключается архитектура, как утверждал Рольф Джонсон, - в коллективном понимании того, как устроена система.

Таким образом, архитектура на 90% оказывает влияние на velocity. Дальше можно долго рассказывать про Coupling&Cohesion, управление сложностью, пределы краткосрочной человеческой памяти, роли типовых решений в коллективном понимании устройства системы, системном мышлении, цикломатической сложности и т.п.

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

В общем, если с velocity беда - то это проблема архитектуры, ну, если только дело не в отвертке в системнике. Системной архитектуры, разумеется.

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

Таким образом проблему можно было бы решить, если бы ее характер был хотя бы линейным. Правда, такой способ может сработать, если хотя бы один из новых синьоров обладает необходимыми знаниями в области системной архитектуры, и сможет изменить характер кривой стоимости изменения кода.

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

Многие знатоки архитектуры утверждают (и я убедился в этом на практике), что, если velocity начал проседать, то он проседает с быстротой экспоненты. Если velocity проседает, то значит есть проблемы на уровне системной архитектуры. Именно об этом и говорит 9-й принцип Agile Manifesto (обсуждали в соседнем чате). И эти проблемы должен кто-то исправить, иначе в бюджете может образоваться дыра неуправляемых масштабов. За кривую экономики разработки отвечает архитектура.

Вторая причина зачем нужно уметь кодить - чтобы помогать разработчикам реализовывать решения. У разработчиков часто возникает страх перед неизведанным, и они стараются ходить обходными путями, когда испытывают неуверенность. Скажем так, среднестатестический разработчик на рынке не сделает Event Sourcing самостоятельно в разумные сроки. Ему минимум месяц-два нужно только готовиться к подобной реализации. И архитектор должен или подготовить команду заблаговременно, чтобы команда успела ознакомиться с теорией и типовыми реализациями, или подключиться к процессу разработки, чтобы команда не завалила сроки. Не обязательно кодить, но он должен понимать и предвидеть потребности команд, и быть готовым выступить куратором, или снабдить информацией, требуемой для реализации.

Из моего личного опыта - когда проект имеет неплохое внутреннее качество (в РФ бывают неплохие проекты), то velocity обычно можно увеличить в течении года раз в 5. Т.е. на ту же сумму можно доставить в 5 раз больше business value. А если проект имеет неудовлетворительное внутреннее качество (что я часто наблюдал на заокеанском рынке), то там только за первые полгода зачастую можно улучшить экономику разработки на пару порядков.

Если velocity слишком низкое - то кто будет тогда реализовывать принимаемые решения? А за кривую velocity отвечает, как я говорил уже ранее, - архитектура.

Самый лучший руководитель, которого я когда либо встречал в своей жизни, был главный инженер одного горно-обогатительного комбината. Невероятно эрудированный человек и тиран. Его все уважали и боялись одновременно. Как-то раз я наблюдал, как он в оперативной диспетчерской комбината разговаривал по телефону со слесарем аварийного водоподъема, и рассказывал ему каким гаечным ключом и какую гайку тот должен открутить. Кстати, интересный момент, который его характеризует - он жил в предоставленном комбинатом жилье, ездил на служебной машине (своей у него не было), и в возрасте 65 лет он каждое утро в 6 утра пробегал несколько километров. Я от этого человека многому научился.

этим всем пусть занимается системный архитектор. Из соседнего чата)

Согласен. Но есть и другая сторона. Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством. Я в свое время писал на emacs, и многие мои друзья писали на emacs, и там по логу можно легко в этом убедиться.

Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система. А именно в этом и заключается архитектура, как утверждал Рольф Джонсон, - в коллективном понимании того, как устроена система.

Таким образом, архитектура на 90% оказывает влияние на velocity. Дальше можно долго рассказывать про Coupling&Cohesion, управление сложностью, пределы краткосрочной человеческой памяти, роли типовых решений в коллективном понимании устройства системы, системном мышлении, цикломатической сложности и т.п.

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

В общем, если с velocity беда - то это проблема архитектуры, ну, если только дело не в отвертке в системнике. Системной архитектуры, разумеется.

Если разработчик 90% времени читает код - то с качеством кода и архитектурой что-то очень не то (

Сколько символов в день коммитят в среднем ваши разработчики? Сколько времени требуется на то, чтобы набрать их на клавиатуре? Вопрос риторический. Если интересно, можете подсчитать. Все остальное время разработчик борется со сложностью и получает представление о том, как устроена система.

Ээ, есть разница между чтением кода и чтением постановок, например. И это не про 'получает представление', эта формулировка очень неточна, нужна какая-то другая.

Но это все про достаточно простые практики качества и тут не будет уходить 90 процентов времени на чтение и понимание системы. Я вообще не уверен в полезности определения Джонсона, если честно.

А при чем тут ввод символов с клавиатуры? Набор кода и изучение системы не исчерпывает деятельности программиста. Понимание и уточнение требований (что и как должно работать) занимает куда как больше времени.