R&D срач

[metaclass]

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

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

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

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

PS: Вот еще на тему - периодически в таких обсуждениях предлагают "положить х-ръ, требовать 100 баксов в час и вообще сесть клиентам на голову и свесить ножки". В этом есть некая проблема, как минимум у меня. Ключевой аспект безумной производительности труда - внутренняя мотивация, которая позволяет делать всю эту дурь не выходя из ритма. Если же начинать думать категориями "мне не доплачивают, я слишком много ебошу, нужно работать 40 часов" - мозг резко выключается и не желает работать даже положенных 40 часов, получая моральное разрешение пинать балду.

Comments

[zamotivator.livejournal.com]

Ну наконец-то хоть кто-то понял меня !

[norguhtar.livejournal.com]

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

Здравствуй Java EE! Правда эти игрища до 5-6 версии мягко говоря бульдозер. В 5-6 лучше, но до spring по внятности и простоте недотягивают. Но Spring это отдельная тема которая офигенно ест мозг и часто производит ощущение ебанной магии. Вроде понятно как что там работает, но ощущение магии не пропадает.

[metaclass.livejournal.com]

Там С++ и адская оптимизация производительности. Т.е. жабьи и даже обычные оопшные методы абстрагирования там слабо применимы.

[alexott.livejournal.com]

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

[metaclass.livejournal.com]

Я бы так и делал. Но похоже, тут основной selling point - производительность, и на нее делается основной упор. А ресурсов одновременно пилить две ветки - правильную и производительную, похоже нет.

[alexott.livejournal.com]

я пилю одну версию - правильную - сначала отлаживаю функционал, потом оптимизую

[jdevelop.livejournal.com]

Java EE тут особо не причем. Это вроде называется системный анализ, или как-то так. В университетах учат даже.

Спринг, при всей своей маркетоидной красоте, тоже не причем в общем )

[metaclass.livejournal.com]

Ага, системный анализ. Я его даже изучал в универе.

[norguhtar.livejournal.com]

Я про модульность, а не про проектирование и анализ :)

[jdevelop.livejournal.com]

ну ладно, тогда интересно почему именно JEE

[norguhtar.livejournal.com]

Хороший пример модульности, с пачкой ручной конфигурации. В spring в разы меньше надо делать.

[jdevelop.livejournal.com]

все равно не понимаю

модульность - это характеристика архитектуры приложения, если я все верно понимаю

конфигурация - это конфигурация собственно приложения

как конфигурация приложения отражается на его модульности?

[norguhtar.livejournal.com]

j2ee предлагает определенные методики для достижения этой модульности, но там пачка вещей автоматически не конфигурируется в этой модульности и приходится писать кучу xml и кода для достижения этого. В случае spring xml надо писать в разы меньше, а кода для конфигурации еще меньше.
Вон товарищ metaclass про тоже пишет ниже.

[metaclass.livejournal.com]

Мне реализация модульности в стиле j2ee и java вообще очень сильно не нравится. Они вытаскивают в конфигурацию даже то, что никто никогда переконфигурировать не будет, ради этого делая грозди паттернов-фабрик-классов-интерфейсов-жуков-жаб.

[norguhtar.livejournal.com]

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

[alll]

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

[zamotivator.livejournal.com]

Перевозка урожая - опердени, танковое сражение - СУБД - я правильно аналогию понял?

[alll]

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

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

[metaclass.livejournal.com]

Отказов чего?

[alll]

http://lurkmore.ru/%D0%91%D1%8B%D0%BB%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BE%D1%82%D0%BA%D0%B0%D0%B7

[develop7]

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

ага. ещё жена может подсказать "40 часов и баста". И тогда действительно баста.

[jdevelop.livejournal.com]

ну на тему второго подхода и производительности - ежу понятно, что "за так" ничего не бывает, чем-то приходится жертвовать. При этом я не призывал взять и все переписать на CORBA, тут скорее вопрос адекватности усилий по поддержке софта. Началось-то все именно с этого, а поддержка компонентов сильно проще поддержки спагетти с ассемблером. Ценой производительности конечно.

Ну а все переключения контекстов, приход более приоритетных задач и общение с кастомерами думаю обсуждать не стоит. У всех свои сложности.

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

[sleepy-drago.livejournal.com]

какое r&d такие и срачки. я вот в "программирование издержек" сейчас не хочу и не надо ляля про удовольствие от сэкономленных на разработке денег. У нас тоже ппц творится и мне кроме багла дают только семечки, но это не повод :)

[(Anonymous)]

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

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