Русские вычислители

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Русские вычислители » Любопытное в Сети » Провал Nitra - для Яра


Провал Nitra - для Яра

Сообщений 1 страница 2 из 2

1

эпичная ветка - http://rsdn.org/forum/nemerle/6404614.all
приведу несколько цитат:

"Нитра рассчитана на языки с динамически расширяемым синтаксисом"
"Нитра — это тоже "всего лишь еще один" тул для создания языков."

"Область применения Nitra это не только DSL а ещё и "развитие любого языка программирования вместе с проектом точно под предметную область". Т.е. проект начинается на языке общего назначения, и превращается в DSL по ходу дела. Видеть в Нитре только DSL-конструктор неправильно."

"«будущее — за DSLями» — это лозунг, а не цель. Более того, совсем непонятная большинству программистов."

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

"3 года работы, технари которые готовят презентацию продукта и сами же ведут роадмап — это факты"

"Я намекаю что проект запустили в формате "мы даём бабло вы делаете всё остальное" а не как надо."

"компания купила сильную идею и очень сильную да ещё и охрененно само-мотивированную техническую команду, но профукала менеджмент"

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

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

"во всех сообщениях я пишу о том, как это может выглядеть со стороны компании (менеджиента, потенциальных «евангелистов», product owner'ов и т.п.). Очень полезно попытаться пробовать смотреть на вещи с их, не инженерной, стороны."

"компании продукт продать не получилось, видимых преимуществ нет, а обещаемые будут неизвестно когда"

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

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

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

"Программистам не хватило сил продать свой проект внутри компании. Сторонние люди во все это вникать не будут. Такое, увы, случается сплошь и рядом."

"Любой вменяемый евангелист на ставке сделает список круче этого и разложит его в серию постов разъясняющих почему срочно надо переходить на суперсет Nitra/C# автокомплит и рефакторинги которого доступны только в IDE от JetBrains или в поставленном ReSharper'е."

"А евангелист об этом суперсете узнает духом святым? Или все же программистам, которые пилят этот суперсет, надо отловить евангелиста, объяснить ему это и запускать дальше?"

"У тебя получается, что компания неизвестно от кого должна была узнать о том, что команда Нитры пилит мегастратегичный проект, в котором можно реализовать (в разумные сроки?) некий мегаязык, который кроет C#, как бык овцу. Как и от кого компания должна была это узнать? Ответь мне на этот вопрос без демагогии про фидбеки и ватерфоллы 90х годов."

"Этот евангелист должен был сам появиться ниоткуда, сам заинтересоваться, сам все сделать и т.п. Не бывает такого. Даже тот евангелист, который был, как видим, ушел. Откуда взяться другому евангелисту, если программисты пилят код и (частично) ни с кем не общаются?"

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

"получается что проекту не было сделано независимой оценки ни в момент принятия решения о взятии его под крыло JetBrains ни в момент когда принималось решение "всех разогнать". Т.е. над технарями-создателями не было поставлено ни одного продукт-менеджера от компании. И ни в один момент никто не задумался о том что такой человек проекту нужен."

"отдельный фронт работ, в котором программирования процентов 20, а общения и писанины текстов процентов 90. В сумме >100 потому что каждая строчка кода в такой роли часть общения с публикой."

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

"Человек курирующий продукт, он же менеджер продукта, и он может совмещать роль евангелиста. Он может даже вести графики закрытия фич и собирать метрики чтобы в день X ответственно заявить — "разработчики божатся что завершат за пол-года, поправочный коэффициент для них ~2.2, так что бета у нас через 9 месяцев, RC через 12, релиз через 13". Если такого не было — его надо было назначить из своих, если таким человеком должен был стать кто-то из "покупаемой" команды, надо было убедиться что его роли не вступили в противоречие. Соответственно этот человек на этапе решения взять проект под крыло, должен был быть отделён от разработки чего-то сложнее примеров использования. Это проклятые азы, об которые убилось немало проектов, и даже древнючая MSF содержала таблички в цветных картинках о том что эту роль совмещать с разработкой нельзя"

"основа основ как и учёт метрик для уточнения оценок сроков. В данном случае на ком-то из разработчиков повисли роли и менеджера продукта и девелопера. Увы, даже ветхие мануалы 15-летней давности говорят что это не взлетит."

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

"Вот у текущего кастомера позиция менеджера совмещает штук 5 ролей в пересчете на наши реалии. И ничего, справляются. Менеджер, архитектор, бизнес-аналитик, полу-прожект, полу-продукт. "

"они выкатили свой SDK. Там было все: и эмулятор, и документация, и first-party приложения, и third-party приложения, примеры и объяснения, что, где и когда делать. Демонстрация возможностей на «седлать за 5 минут», «сделать за 2 дня», «сделать за 2 недели»."

"Перевести всю Нитру на другую платформу будет не просто. Для этого сначала на нитре надо переписать Немерл и забутстрапить с ним саму Нитру."

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

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

"расширяемость (языка программирования) действительна интересна в экспертных системах (обработки знаний), где понятия естественного языка прямо проецировались и компилировались в понятия и правила (программные узлы, связи) целевой системы. Для ускорения анализа."

"Нужны не трёхчасовые презентации раз в три года, а постоянные демонстрации хоть чего то полезного. Пусть это работает долго и коряво, зато можно потрогать и пощупать. Собтсвенно приседания с IDE нужны в последнюю очередь — индустрия десятками лет спокойно хавает всевозможные препроцессоры."

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

"что продаётся подсказывают сейлзы" "Если принципиально новая идея, как разработчики утверждает, то никакой менеджер эту работу не сделает."

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

"хочешь инвестиций — учись играть по правилам того бизнеса, у которого берёшь деньги. Других вариантов нет. Бизнес за идею не работает."

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

"У нас менеджеры получают ЗП за то, что команда забивает голы. А ты и Влад ждете, что менеджеры сами будут по полю бегать"

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

"В случае программирования — бегать по полю это писать код. Где ты сумел прочитать что менеджеры должны писать код? Ты лучше напиши что по-твоему они вообще должны делать? Вот случилось 9 утра, пришли, включили компы, дальше что? У тебя получается что дальше всё — пьём кофе и ждём пока "команда забьёт голы"..."

"С удовольствием поржу над судьбой любого проекта в котором список текущих задач для разработчиков ведут на уровне рекламных текстов"

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

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

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

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

"стратегический маркетинг лежит не на продажниках, а вообще на менеджменте."

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

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

"для тех кому точные сроки хоть сколько-то важны за последние лет 10 вышла куча мануалов упоминающих story points и как их потом переводить в часы."

"Для конторы меньше 100 да аутсорс очень накладно держать R&D. У них заработок N-разрабов помножить на рейт — прибыль ничтожная."

"у меня из тех же источников появилось совсем другое ощущение — проект неокупаемый и идет в тупик"

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

"И вот такие вопросы нас плавно приведут к тому что команда была, а управления не было. Кто отвечает за управление? Твой пойнт понятен — они сами и отвечают. Так если технари должны всё сами, возвращаемся к вопросу нафига тогда вообще девелоперам менеджмент"

"В этот момент наш гипотетический техдир должен осознать что Влад подставлен под конфликт ролей... и забить?"

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

"Судя по сообщениям Влада, он именно им и был. Все рекламные посты — от него. Иногда бывают настолько упёртые и упоротые личности, что никаким хреном роли не отберёшь, все равно будет заниматься тем же."

"менеджер лучше программистов представляет "что делаем и когда будет готово" — это его работа. И если ему мало информации — он инициирует коммуникацию, а не ждёт пока разработчики сами догадаются или задаёт односложные вопросы типа "когда?""

"В аутсорсе проекты дохнут по разным причинам постоянно. Контора учитывает все такие риски"

0

2

"Нитра рассчитана на языки с динамически расширяемым синтаксисом"
"Нитра — это тоже "всего лишь еще один" тул для создания языков."
"Область применения Nitra это не только DSL а ещё и "развитие любого языка программирования вместе с проектом точно под предметную область". Т.е. проект начинается на языке общего назначения, и превращается в DSL по ходу дела. Видеть в Нитре только DSL-конструктор неправильно."
"«будущее — за DSLями» — это лозунг, а не цель. Более того, совсем непонятная большинству программистов."

Расширение языка понятными словами из предметной области всегда лучше чем синтаксисом заумными обозначениями. Популярнее языки, где больше библиотек, нет необходимости переучивать основу, которые по крайней мере выгоднее в отношении "объем покрытия потребностей/сложность синтаксиса".
Поэтому одновременно с монстрами вроде С++, Java или JS живы и древнейшие Си, Лисп, даже Пролог как-то дышит, хоть и в узкой области.
И если для чего-то возникнут удобные особые обозначения, не вписывающиеся в популярный язык, его легко расширят сразу же и без нужды в новых соглашениях, например, для начала будут писать в кавычках, как SQL-запросы или регулярные выражения.

0

Быстрый ответ

Напишите ваше сообщение и нажмите «Отправить»



Вы здесь » Русские вычислители » Любопытное в Сети » Провал Nitra - для Яра