"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
(с) Волков, Танки Онлайн, неточная цитата.

Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.

Я лично участвовал в пяти проектах, которые развивались по этой схеме. Вот результаты:
1. Три полностью провалились (т.е. были отменены после того, как сожрали изрядно денег и не дали никакого полезного результата).
2. Один еле вытащили до состояния shippable-продукта (т.е. все обещанные плюшки от разработки платформы пошли лесом, оставив переусложненную и нестабильную кодовую базу, в которую были зарыты крупные деньги).
3. Один, участником которого я являюсь сейчас, так же борется за жизнь, но есть сильный риск того, что он повторит первый или второй сценарий.
Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.

"Тенденция, однако" (с)

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

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

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

Зло, о котором я говорю — это именно такой подход, а не результат.

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

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

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

Зоны комфорта, бла-бла...
Просто фреймворки и платформы гораздо прикольнее разрабатывать , вот и всё.

You will always get what you always got
  If you always do  what you always did

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

J>Зоны комфорта, бла-бла...
J>Просто фреймворки и платформы гораздо прикольнее разрабатывать , вот и всё.
Вот взял и всё опошлил

J>

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

0>"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
0>(с) Волков, Танки Онлайн, неточная цитата.

0>Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.
0>Вообщем, наброс сделан, жду ваших мнений

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

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

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

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

В любом случае, я критикую не идею разработки платформы в принципе, я критикую метод принятия решения.

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

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

0>> Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта.

J>Зоны комфорта, бла-бла...
J>Просто фреймворки и платформы гораздо прикольнее разрабатывать , вот и всё.

Тавтология. Вот 0x7be и пытается объяснить, почему "прикольнее".

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

0>Я лично участвовал в пяти проектах, которые развивались по этой схеме.
Да мы с вами коллеги

0>

0>"Тенденция, однако" (с)

Подтверждаю.

0>Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе.
У вас была одна проблема. Для её разработки вы решили сделать/использовать платформу/фреймворк — теперь у вас две проблемы

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

0>Зло, о котором я говорю — это именно такой подход, а не результат.
+100500

Ну, и как бы, вот https://medium.com/p/db854689243

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

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

Как только программист глядя на описание новой фичи задаёт вопрос "зачем?", его тут же выгоняют в тимлиды, а потом в менеджеры проектов. Программистами остаются только те, кого интересует только написание кода за деньги

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

A>Как только программист глядя на описание новой фичи задаёт вопрос "зачем?", его тут же выгоняют в тимлиды, а потом в менеджеры проектов. Программистами остаются только те, кого интересует только написание кода за деньги
Да, примерно так оно и есть
Толковых лидов и менеджеров не хватает

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


0>Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.
про ехель знаете? на его примере можно проследить всю судьбу винды. очень многое из того, что есть в винде было реализовано в ехеле, ну или в офисе.

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

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

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

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

ЗЫ. когда я начинал изучать JS, то первое что я стал писать -- это логгер. шеф покрутил пальцем и виска и показал на готовый, которым до сих пор пользуюсь.

Здравствуйте, мыщъх, Вы писали:

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

М>ЗЫ. когда я начинал изучать JS, то первое что я стал писать -- это логгер. шеф покрутил пальцем и виска и показал на готовый, которым до сих пор пользуюсь.
Боюсь, есть недопонимание. Я ничего не имею против фреймворков в принципе, я имею кое-что против определённого ущербного мыслительного процесса, который приводит к появлению нежизнеспособных фреймворков.

Что характерно, в моём сообщении уже не первый раз видят наезд на концепцию плафтормы/каркаса в принципе. Либо я так неудачно выразился, либо это тоже особенность мышления нашего брата-программиста

0>технарям просто психологически комфортнее делать технологию, а не конечный продукт
Всё гораздо проще, программистам некомфортно делать бесполезную работу (которую можно автоматизировать и переложить на машину). Для кого эта разница в "написании кода за деньги" незаметна, тот, скорее всего, не программист, а простой клерк-делопроизводитель.
http://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself
Появляется, например, бизнес-задача поменять 1 слово в 100 похожих экранных форм. С фреймворком эта задача решается изменением 1 места в коде, а без фреймворка — долгим и внимательным ручным тиражированием этого изменения в 100 откопипастенных-с-изменениями мест, и последующим отловом ошибок, сделанных при тиражировании.

0>Вообщем
"Нутыпонел".

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

0>>технарям просто психологически комфортнее делать технологию, а не конечный продукт
O>Всё гораздо проще, программистам некомфортно делать бесполезную работу (которую можно автоматизировать и переложить на машину). Для кого эта разница в "написании кода за деньги" незаметна, тот, скорее всего, не программист, а простой клерк-делопроизводитель.
O>http://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself
O>Появляется, например, бизнес-задача поменять 1 слово в 100 похожих экранных форм. С фреймворком эта задача решается изменением 1 места в коде, а без фреймворка — долгим и внимательным ручным тиражированием этого изменения в 100 откопипастенных-с-изменениями мест, и последующим отловом ошибок, сделанных при тиражировании.
Ты описываешь ситуацию оправданного внедрения обобщенного решения. Я же говорю о тех мыслительных процессах, которые приводят к появлению мертворожденных фреймворков и платформ, чему я был свидетелем неоднократно.

Я согласен с тем, что мотив облегчить себе жизнь на будущее разработав изначально обобщенное решение имеет место быть и очень часто озвучивается. Беда в том, что очень часто я вижу как руководствуясь этим благим намерением люди заводят проект в тупик: городят огромные и нестабильные решения, которые потом на практике ещё и с трудом решают прикладные задачи под которые создавались. То есть на поверку получается та же самая бесполезна работа, которая обходится намного дороже.

В чем причина такого положения дел?
Я предложил гипотезу

0>городят огромные и нестабильные решения, которые потом на практике ещё и с трудом решают прикладные задачи под которые создавались. То есть на поверку получается та же самая бесполезна работа, которая обходится намного дороже.
0>В чем причина такого положения дел?
В том, что иногда видят только одну крайность, и игнорируют другую. Необходим баланс между решением сиюминутной задачи и созданием задела на будущее. И для тех, кто сегодняшнюю задачу сдал/премию получил/а дальше хоть трава не расти, и для тех, кто тратит время на создание расширяемости, которая потом не будет использоваться.

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

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

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

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

0>>Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе.
A>У вас была одна проблема. Для её разработки вы решили сделать/использовать платформу/фреймворк — теперь у вас две проблемы

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

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

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

История и Unix, и Windows — история успеха того, что началось как "склёпанный быстро поток кода", превращённый в платформу, пережил несколько десятилетий.

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

Программисты начиная с Hello World используют уже готовые фреймворки. Как следствие понимание что какое-то количество обобщённого кода может решать спектр задач и это лучше чем лепить уникальное решение для каждой в отдельности, приходит очень-очень быстро. Собственно без выделения общих участков (функции, классы, компоненты), программистом стать нереально. Исключения конечно есть, например тут код РАБОЧЕЙ игры, но всё-таки нереально.

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

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

0>>технарям просто психологически комфортнее делать технологию, а не конечный продукт
O>Всё гораздо проще, программистам некомфортно делать бесполезную работу (которую можно автоматизировать и переложить на машину). Для кого эта разница в "написании кода за деньги" незаметна, тот, скорее всего, не программист, а простой клерк-делопроизводитель.
O>http://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself

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

Ой ребе, не начинайте.
Это работает и в обратную сторону: надо сделать какую нибудь простую штукенцию, но для этого надо создать фабрику фабрик синглтонов фабрик объектов, написать несколько XML, которые это всё описывают и с подвыподвертом это всё вызывать.

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

_>Программисты начиная с Hello World используют уже готовые фреймворки. Как следствие понимание что какое-то количество обобщённого кода может решать спектр задач и это лучше чем лепить уникальное решение для каждой в отдельности, приходит очень-очень быстро. Собственно без выделения общих участков (функции, классы, компоненты), программистом стать нереально. Исключения конечно есть, например тут код РАБОЧЕЙ игры, но всё-таки нереально. Опыт по созданию обобщённого кода приходит годами позже. Иногда отсутствие опыта на одних уровнях (архитектура, бд, использование готовых решений), удаётся компенсировать опытом на других уровнях. А иногда получается то что ты наблюдаешь.
Одно дело — обобщать код в работающей (хотя бы частично) программе, другое дело — вместо работающей программы писать неработающий фреймворк.
Я говорю именно о втором феномене.