Об изготовлении программ и ежиках в тумане

Спасибо, Алексей!
Не скрою, ждал очередного текста от Вас с нетерпением и надеждой.
В конце июня надеюсь быть в Н-ске, м.б. поговорим.

Крайне актуальная статья.

Очень актуальная проблема. С одной стороны, вроде бы, софт уже написан и бесплатен, но, с другой стороны, качество его таково, что часто легче написать, а проще и быстрее купить коммерческий аналог.
Что делать?
Может быть 2-3 группы разработчиков, объединив свою репутацию, могли бы … тут возможны варианты. Проще всего, например, сделать присуждаемый за качество знак. Наличие знака у софта значит, что за этот софт (за его качество, полноту его описания и пр.) кто-то отвечает. В случае проблем он обязуется помочь разобраться и, если понадобится, исправить свой софт. Если софт качеством не соответствует, и автор не выполняет - знак отбираем. Каждое успешное использование - повторный знак.
Тогда любой пользователь предпочтет софт с максимальным количеством значков. И заказать разработку у того, кто больше этих знаков набрал … и т.д.

Анатолий, поговорить - это здорово, только я давно живу/работаю в Питере, так что в Н-ск встретится никак не смогу

"Может быть 2-3 группы разработчиков, объединив свою репутацию, могли бы … тут возможны варианты. Проще всего, например, сделать присуждаемый за качество знак" - на мой взгляд тут нужна работа ассоциации производителей ПО или государства. Из статьи я убрал слова по "Центры сертификации" (чтобы не перегружать), но делать что-то в этом направлении надо.

Государству я попытался подсказать что делать. Мой опыт - в статье про "предцифровую горячку" здесь же примерно года полтора назад. Если бы я всерьез рассчитывал на реакцию государства, то настаивал бы на тех рекомендациях. но думаю, что 2-3 группы разработчиков белее реально.
А центы сертификации мне не нравятся: т.к. они быстро превратятся в еще одну кормушку для кормежки чиновников.

Почему я говорю про Центр сертификации (естественно не государственный и не имеющий право запрешать/разрешать)?

1) Работы много. Чтобы проверить качество, надо иметь свою систему тестирования, независимую от разработчика. Надо уметь проверять качество и адекватность не только кода, но и документации. Надо проверять все интерфейсы на стандартность взаимодействия. И так для каждой новой версии.

2) Чем будут зарабатывать себе на хлеб 2-3 команды разработчиков? У меня нет вариантов. Разве что им будут платят за то, что они такие хорошие , но тогда надо сначала эту "хорошесть" показать/доказать, а для этого нужно много поработать и деньги (catch 22).

На мой взгляд, единственным вариантом может быть некоммерческая ассоциация крупных разработчиков, возможно, с гос. участием, которые вкладывают деньги в независимую сертификацию. Но ассоциация может состоятся только когда крупные разработчики окончательно упрутся в тупик, а пока "все хорошо, прекрасная маркиза".

Добавлю, что стандартизация open source - это малая часть того, что надо сделать для выхода из тумана.

Алексей, можете привести экономические расчёты предполагаемой модели разработки для разного количества людей, вовлечённых в разработку - от микро до макро уровня?

Отлично! "Agile - это палка для слепого, это технология от бедности и от отчаяния"

Все перечисленные странности - 20+ летней давности.

Почему архитектуру делает "Конструктор"? "описание системы задает архитектуру системы, только не нарисованную, действующую - живую" - вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises

"вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises"

Посмотрел статью. Интересный подход к частной задаче (Enterprise Management System). Вы предлагаете собрать IT систему по бизнес архитектуре из микросервисов.

Вопрос: А как вы будете решать основные проблемы (не наблюдаемость, сложные и противоречивые настройки/конфигурации, несовместимость, отсутствие стабильных интерфейсов, отсутствие адекватной документации)?

Слова сказаны хорошие, но вот решения за ними я не вижу.

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

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

На мой взгляд, поза "архитектура сверху" не решает задачу. Архитектура должна быть не сверху, а снизу и между. Для лучшего понимания, вместо слова "архитектура" стоит использовать "основа" или "скелет". Сначала надо собирать скелет (без компонент, микросервисов, подсистем), и только потом подключать те части, которые "совместимы" со скелетом. Скелет должен обеспечивать: наблюдаемость, конфигурируемость, отказоустойчивость, расширяемость, масштабируемость и т.п.

Скелет естественно должен быть гибким, и вся система должна изначально строится как максимально гибкая (динамичная), а потом оптимизироваться (там где возможно и в идеале только автоматически).