А если серьезнее, то velocity разработки является скорее вредной (в лучшем случае бесполезной) метрикой. Так как произвольна и не связана естественным способом с параметрами успеха компании. Таким образом не стоит обсуждение архитектуры связывать с velocity вообще.

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

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

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

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

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

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

Выменивать — да. Бартер. Хотя явно проблемы с процессами, но это в другом ключе решать.

А "под ногами сервер" — ГОСТЫ хоть и древние, а правила игры в этом ключе определяют. Так что контекст не нужен, давно определено и дано заключение. Не мной кстати.

Выменивать — да. Бартер. Хотя явно проблемы с процессами, но это в другом ключе решать.

А "под ногами сервер" — ГОСТЫ хоть и древние, а правила игры в этом ключе определяют. Так что контекст не нужен, давно определено и дано заключение. Не мной кстати.

Мне отрадно, что экстремальный кейс из стартапа начала нулевых вытащил столько деталей в обсуждении!

По деталям -- сервер не был ни у кого под ногами. Лид был расстроен информацией, которую я на него вывалил. Инфа была правильной, моя подача -- нет.

После этого он пошёл, как потом рассказывал, что-то чинить. И в работающем сервере перевел на блоке питания переключатель с 220 на 110.

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

Да, и почему ГОСТ должен задавать правильные практики в этом контексте?

Нашу область действий тогда гораздо лучше описывал какой-нибудь lean product development. До зрелых практик вроде segregation of duties тогда было, как до луны -- риски в другой области были основные.

Хорошее сравнение но не согласен. Я в курсе уровня зп. Не всегда арх выгоднее. Не всегда он знает больше. Скорее это человнк в шапке с логотипом бизнеса. В условиях 7 лет падающего рынка может быть выгоднее на шапке написать какуюто технологию.

Чтоб не было недопонимания, отвечу картинкой, о чем я веду речь.

> А если серьезнее, то velocity разработки является скорее вредной (в лучшем случае бесполезной) метрикой. Так как произвольна и не связана естественным способом с параметрами успеха компании. Таким образом не стоит обсуждение архитектуры связывать с velocity вообще.

Ваше мнение мне понятно.
А теперь, я хотел бы уйти от софистики и восстановить контекст разговора. Он заключался в средующем:

"В BDUF это не критично. А в итеративных разработках - критично."

Послушаем мнение, альтернативное вашему:

"At the core of understanding this argument is the software change curve. The change curve says that as the project runs, it becomes exponentially more expensive to make changes. The change curve is usually expressed in terms of phases "a change made in analysis for $1 would cost thousands to fix in production". This is ironic as most projects still work in an ad-hoc process that doesn't have an analysis phase, but the exponentiation is still there. The exponential change curve means that evolutionary design cannot possibly work. It also conveys why planned design must be done carefully because any mistakes in planned design face the same exponentiation.

The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire."
- "Is Design Dead?" by M.Fowler
https://martinfowler.com/articles/designDead.html

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

Еще раз подчеркну самое главное: "The exponential change curve means that evolutionary design cannot possibly work."

Речь шла не о метриках, а о velocity в контексте стоимости изменения кода (о чем я говорил в т.ч. прямым текстом). И, если вы не видите в этом пользу для бизнеса, то отцы-основатели массовой итеративной разработки утверждают, что, без этого условия, "evolutionary design cannot possibly work".

Имеет ли "evolutionary design" (по сути - возможность итеративной разработки) значение для бизнеса? На эту тему можно долго дискутировать, но вывод будет однозначный - имеет, особенно в условиях скоротечно меняющейся рыночной обстановки. Проекты, утратившие гибкость и неспособные адаптироваться к новым рыночным вызовам, просто выбывают из конкурентной гонки (по крайней мере, я знаю уже несколько таких).

Эгм, очень странная картинка. Я не понимаю, в каких процессах объединяется coding и debugging. И зачем так много внимания такой малозначимой стадии разработки ПО, когда она редко бывает критичной.

Это жертва потерянного контекста. Обратите внимание на подпись к рисунку.

Это начало Code Complete Макконнелла -- единственной его книги, полностью сфокусированной на кодинге.

Это жертва потерянного контекста. Обратите внимание на подпись к рисунку.

Это начало Code Complete Макконнелла -- единственной его книги, полностью сфокусированной на кодинге.