0>Ок, к моей "психологической гипотезе" добавим банальные недостаток компетенций
Это самый простой способ "решить вопрос для себя" — объявить всех некомпетентными психами, но работать-то в таком случае с кем, и договариваться как?
0>Видимо, так же можно говорить и про несовпадение целей проекта и его исполнителей.
Смысла в этом столько же, как если каждый раз, заходя в магазин, говорить про несовпадение целей продавца и покупателя.
И раз уж зашла речь о компетенциях, распространена ситуация, когда заказчик не совсем понимает, чего он хочет. "Здесь же всего одну кнопку добавить для расчёта баланса, любой студент за полчаса сделает". Или как в хрестоматийном примере про "выстрелить себе в ногу". Наверно, здесь нужен подход, типичный для ситуации, когда специалист лучше разбирается в предмете (как врач по сравнению с пациентом): заказчик варьирует "наружные" параметры (функционал, сроки, бюджет), специалист предлагает решение, заказчик целиком принимает или целиком отвергает, но во внутренние технические детали не вмешивается.

CC>Ой ребе, не начинайте.
CC>Это работает и в обратную сторону: надо сделать какую нибудь простую штукенцию, но для этого надо создать фабрику фабрик синглтонов фабрик объектов, написать несколько XML, которые это всё описывают и с подвыподвертом это всё вызывать.
Это не "работает в обратную сторону, а просто "не работает". Вместо замены ручного труда на автомат — заменили на такой же ручной труд, только в другом месте. DRY-принцип как не соблюдался, так и не соблюдается. Можно пример "простой штукенции", для большей предметности?

Опыт программиста в том и заключается — насколько далеко надо пустится в написание фреймворков, чтобы выполнить проект.
Вы, по рассказу, увлекались этим чрезмерно. Это опасно, да.

Но я видел и другие проекты — где просто не давали ничего сделать на перспективу.
Итог — куча гвнокода, и тоже ничего не работает толком.

Здравствуйте, barn_czn, Вы писали:

_>Опыт программиста в том и заключается — насколько далеко надо пустится в написание фреймворков, чтобы выполнить проект.
_>Вы, по рассказу, увлекались этим чрезмерно. Это опасно, да.
Ну, на моей совести один из описанных проектов. Тот как раз, который еле вытащили до состояния shippable-продутка

_>Но я видел и другие проекты — где просто не давали ничего сделать на перспективу.
_>Итог — куча гвнокода, и тоже ничего не работает толком.
Согласен, крайности опасны.

Я участвовал в одном проекте, где было сделано на мой взгляд разумно. Там писался один продукт, но планировалось писать другой, в целом аналогичный по структуре.
По ходу работы все компоненты "на глазок" делились на общие и специфичные, но заранее дорогих закладок на второй продукт не делалось.
Потом, когда начали делать второй продукт, общий функционал стали агрессивно выделять в разделяемый код и так "вырос" небольшой framework, реально позволивший сэкономить время при разработке второго продукта.

Здравствуйте, 0x7be, Вы писали:

0>Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value. Разработчики — эгоцентристы, им некомфортно влезать в шкуру пользователя, учиться смотреть на мир его глазами, понимать его проблемы, получать от него негативный фидбек. Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта. Технология делается не для пользователей, а для самих себя (или же других разработчиков), так что можно обойтись привычной картиной мира критериями оценки результата, да и общаться с потребителем проще.

"Технология" это обычно слишком громкое слово для большинства фреймверков. Язык не поворачивается их так назвать

Здравствуйте, Географ, Вы писали:

Г>Тем не менее, любое успешное решение, пережившее не одну версию, изначально создавалось на какой-либо платформе. Просто поток кода, склёпанный быстро, решает только одну задачу, на вторую его уже не согнуть.

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

Здравствуйте, Lazin, Вы писали:

L>"Технология" это обычно слишком громкое слово для большинства фреймверков. Язык не поворачивается их так назвать

я примерно об этом вот — https://github.com/search?q=framework&ref=cmdform

большинство перечисленных "фреймверков" делают какую-нибудь простую хрень, достойную библиотеки, но никак не громкого слова "фреймверк", субъективно конечно

Здравствуйте, Lazin, Вы писали:

L>"Технология" это обычно слишком громкое слово для большинства фреймверков. Язык не поворачивается их так назвать
Простите моему вбросу некоторые терминологические вольности

Здравствуйте, Osaka, Вы писали:

0>>Ок, к моей "психологической гипотезе" добавим банальные недостаток компетенций
O>Это самый простой способ "решить вопрос для себя" — объявить всех некомпетентными психами, но работать-то в таком случае с кем, и договариваться как?
Я не собираюсь развешивать ярлыки
Тему поднял и исключительно благими целями — понять, почему люди по одним и тем же граблям систематически ходят.

O>Смысла в этом столько же, как если каждый раз, заходя в магазин, говорить про несовпадение целей продавца и покупателя.
Не до конца уловил смысл предложения.

O>И раз уж зашла речь о компетенциях, распространена ситуация, когда заказчик не совсем понимает, чего он хочет. "Здесь же всего одну кнопку добавить для расчёта баланса, любой студент за полчаса сделает". Или как в хрестоматийном примере про "выстрелить себе в ногу". Наверно, здесь нужен подход, типичный для ситуации, когда специалист лучше разбирается в предмете (как врач по сравнению с пациентом): заказчик варьирует "наружные" параметры (функционал, сроки, бюджет), специалист предлагает решение, заказчик целиком принимает или целиком отвергает, но во внутренние технические детали не вмешивается.
Это называется "выстраивание отношение с клиентами". Есть даже такая отдельная компетенция, про неё очень любят говорить во всяком консалтинге. Понять клиента, сделать не то, что он хочет, а то что ему надо, сформировать у него реалистичные ожидания насчет стоимости его хотелок и т.п..

У нас же клиента часто априори считают дебилом, т.к. он не рубит в разработке, а его потребности, не вписывающиеся в красивую архитектуру программы, вызывают раздражение.
Мне один архитектор (главный, между прочим!) не так давно выдал мысль, мол, лучше бы проектировать всё без специалистов по взаимодействию с пользователем, а их позвать только в самый последний момент. Дескать мешаются, гады, творить и ваять.

Всё это я понимаю, как проявление эгоцентризма разработчиков, о котором я в оригинальном посте написал.

Здравствуйте, 0x7be, Вы писали:
0>Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.
Была такая тема некоторое время назад — что все ошибки проектирования — это результат каких-то фобий.
То есть, к примеру, программист Паша однажды обжогся на том, что его программа численного моделирования работала медленно. Он потратил три месяца на то, чтобы разобраться в том, как устроен компьютер внутри, и с ужасом обнаружил, что Borland C++ 3.01 при target CPU = Blend генерирует совершенно отвратительный код с плавающей запятой. Если сравнивать его с вручную выпиленным ассемблером, заточенным под SSE3.
С тех пор прошло 25 лет, но Паша по прежнему не доверяет компиляторам без директивы asm.

Программист Валера однажды обжогся на том, что студенты первые четыре месяца лабораторного практикума борются с тем, чтобы заставить компилироваться Hello World на языке C. А потом за оставшиеся три дня им нужно сдать десять лабораторок для получения допуска к экзамену. С тех пор прошло 25 лет, среды разработки стали гораздо умнее, но Валера по-прежнему считает, что ручной набор — корень всех зол, и продолжает мечтать о среде графического проектирования синтаксических деревьев.

А программист Дима однажды обжогся на том, что его чудо-программа всё время находится в 1 шаге от успешного запуска у заказчика, и всё время мешаются какие-то мелочи. То винда у заказчика находится не на диске С:\; то надо кнопку "Выход" переименовать в "Завершение сеанса", то ещё что. И Дима, устав ездить обратно к машине с компилятором, уже 25 лет пилит приложение, которое можно полностью переконфигурировать без компиляции, путём простой правки строчек данных в таблицах. При условии, что база с именем project1 лежит в в дефолтном инстансе SQL Server, задеплоенном на текущей машине.
(Если Дима в детстве начинал работать не на ФоксПро, то вместо базы будет набор конфиг-файлов).
В итоге Дима получает ещё один Тьюринг-полный язык программирования для "конфигурирования приложения". Теперь ему надо чинить баги не только в самой программе, но и в "конфигурации", объем которой вскоре начинает превышать объем исходников "платформы" (если Дима начал до 2000х) или "фреймворка" (если Дима начал после 2000).
Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer. Это как бы показывает, что overarchitecting не является специализацией провинциальных кулибиных, а запросто может процветать и в корпоративном секторе.

Здравствуйте, Sinclair, Вы писали:

S>Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer.

Да, да, тысячу раз да! Я готов истоптать семь пар лаптей, но дойти-таки до Редмонда и с неизбывной русской тоской посмотреть в глаза тому индусу, который это чудо спроектировал.

Здравствуйте, Sinclair, Вы писали:

S>Была такая тема некоторое время назад — что все ошибки проектирования — это результат каких-то фобий.
Не, ну я не про фобии, я про эгоцентризм

S>Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer. Это как бы показывает, что overarchitecting не является специализацией провинциальных кулибиных, а запросто может процветать и в корпоративном секторе.
Люто, бешено плюсую.
Желание придушить разработчиков этой фигни у меня возникает минимум раз в день

Здравствуйте, Sinclair, Вы писали:

S>Пример проекта, который преодолел испытание "реляционной конфигурируемостью" и был сквозь зубовный скрежет навязан целевой аудитории, каждый может наблюдать в лице Windows Installer. Это как бы показывает, что overarchitecting не является специализацией провинциальных кулибиных, а запросто может процветать и в корпоративном секторе.

Да че за бред-то???
Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.

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

Здравствуйте, vdimas, Вы писали:

V>Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.

Начнем издали: насколько плотно ты работал с MSI и видел ли, как он устроен изнутри?

Здравствуйте, 0x7be, Вы писали:

0>Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value.

Я бы добавил еще недооценку сложности проблемы и переоценку собственных сил.

Ну и мозг подставляет подножку своим умением натягивать сову на глобус. Изучив 5-10% описания проекта, мозг подгоняет оставшееся под уже привычные шаблоны, в результате чего возникает ощущение, что создание framework-а это просто самый рациональный быстрый способ создания программного продукта. А потом оказывается, что абстракции, которые в первом приближении так идеально отвечали всем потребностям проекта, ни фига не работают. Попытка решить одним потоком управления несколько разных задачи приводит к классической дилемме "хвост вытащишь — нос воткнешь, нос вытащишь — хвост воткнешь".

Здравствуйте, Osaka, Вы писали:

O>Появляется, например, бизнес-задача поменять 1 слово в 100 похожих экранных форм. С фреймворком эта задача решается изменением 1 места в коде, а без фреймворка — долгим и внимательным ручным тиражированием этого изменения в 100 откопипастенных-с-изменениями мест, и последующим отловом ошибок, сделанных при тиражировании.

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

Здравствуйте, 0x7be, Вы писали:

0>Ты описываешь ситуацию оправданного внедрения обобщенного решения. Я же говорю о тех мыслительных процессах, которые приводят к появлению мертворожденных фреймворков и платформ, чему я был свидетелем неоднократно.

Еще одна причина в боязни, что кто-то назовет твое творение говнокодом.

Здравствуйте, Mystic, Вы писали:

M>В жизни я чаще наблюдаю ситуацию, когда и в случае framework-а все равно приходится менять ручками одно слово на сотне экранных форм.

Обычно всё еще хуже. Нужно написать свой преобразователь текста, который создается при помощи фабрики фабрик фабрик объектов и работает через крайне мутный АПИ, и записать параметры его вызова в сотню конфигов.

Здравствуйте, 0x7be, Вы писали:

0>Желание придушить разработчиков этой фигни у меня возникает минимум раз в день

Самая кривая и убогая технология, по моему персональному рейтингу. Даже не знаю, бывает ли хуже.

Здравствуйте, 0x7be, Вы писали:

0>Вообщем, наброс сделан, жду ваших мнений

У меня несколько противоположный опыт.
Все успешные и серьезные компании которые имеют какой-нибудь успех используют свои собственные frameworks и platforms.
Например из тех что я знаю достоверно Amazon, Google, Twitter, Facebook, Microsoft и т.д.
Это все про Web UI frameworks.