29.12.2011 23:20, minorlogic пишет:
> А>Мой вывод, основанный на печальном опыте, таков, что говноменеджер > может сделать говнокод, имея даже команду самых лучших программистов. > > Лучшие програмисты не допустят навязывания безграмотных технических решений.
Они уволятся (или их уволят). В итоге останется говноменеджер с
говнопрогерами.
Здравствуйте, minorlogic, Вы писали:
А>>Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов.
M>Лучшие програмисты не допустят навязывания безграмотных технических решений.
Это каким образом ? Приходит менеджер и говорит — фичу надо сделать завтра. Работы реально около месяца. Неужели самые лучшие программисты могут любую фичу в любой сколь угодно малый срок реализовать ?
Здравствуйте, pagrus, Вы писали:
P>Я с большего согласен, и добавлю несколько соображений.
P>* Кроме менеджера есть ещё множество переменных окружения, ведущих к плохому коду. Представьте, что вы унаследовали сташный codebase.
Со страшным codebase, т.е. легаси-код, есть методы борьбы. Если менеджмент понимает это, проект можно реанимировать. Чем более убитый код, тем больше зависимость именно от менеджмента, а не программистов. Убитый код делает создает проблемы на ровном месте. Если менеджмент этого не понимает, то проблемы никогда не будут решены. То есть проект будет становиться все более дорогим.
P>* Хороший менеджмент — не гарантия хорошего кода. Представльте, что в условиях крайне ограниченного бюджета, с командой из джуниоров, менеджер ухитряется держать проект достаточно прибыльным, клиента достаточно довольным, и команде даже местами бонусы перепадают. Но при этом фигурирует ожидаемый говнокод. Был бы менеджер лучше, если б стал горой за качество кода, и потерял бы клиента и/или нанёс ущерб работодателю?
Как то странно рассматривать качество кода отдельно от бизнеса. Качественный код это не тот, который красиво выглядит. Качественный код это такой, который позволяет вводить фичи эффективно (стоимость/время) в краткосрочной, среднесрочной и долгосрочной перспективах.
Например если посрезать все углы( или накопипастить), то фичи появятся очень быстро. Зато через год придется
1 изыскать все места этих ускорений
2 пофиксить их
3 все смежные
4 реализровать фичу, периодически повторяя 1...3
Если для проекта актуальна долгосрочная перспектива, то менеджмент должен быть в курсе и доводить это до исполнителей. В противном случае самые классные решения созданые самымаи лучшими программистами будут тупо говнокодом.
P>* Вместе с тем, есть разработчики, хронически неспособные производить говнокод. Как на них не дави, в какие условия не ставь, они будут делать качественно. Может, не попадут в ожидания менеджмента и как-бы всех подведут по срокам. Может, не вписавшись, "проголосуют ногами" из такой конторы. Но не выдадут говнокод.
Не бывает такого. Временные решения == говнокод. done-cbb == говнокод. Решение в лоб == говнокод. Промежуточные решения == говнокод. Решения под старый набор требований == говнокод. Очень тяжело после каждого фикса пересматривать весь проект в целом, потому этапы говнокода у хороших разработчиков чередуются с этапами очистки кода от мусора.
Здравствуйте, Vzhyk, Вы писали:
>> Лучшие програмисты не допустят навязывания безграмотных технических решений. V>Они уволятся (или их уволят). В итоге останется говноменеджер с V>говнопрогерами.
Хороший программист это тот кто выдаёт результат, а не отказывается от результата под каким либо предлогом.
09.01.2012 12:20, Ikemefula пишет:
> Хороший программист это тот кто выдаёт результат, а не отказывается от > результата под каким либо предлогом.
В любой сколь угодно малый срок?
Здравствуйте, Vzhyk, Вы писали:
>> Хороший программист это тот кто выдаёт результат, а не отказывается от >> результата под каким либо предлогом. V>В любой сколь угодно малый срок?
А что тебя смущает ? Меньше срок — меньше(хуже по каким то критериями) результат. Один из результатов работы программиста это доведение до сведения руководителя о такой вот зависимости в самых разных формах.
Если ты разрабатываешь фичу, то как правило, представляешь какие ограничения у твоего решения. Вот их в частности нужно согласовывать с менеджером, что бы он был в курсе, когда будет принимать решение о сжатых сроках.
09.01.2012 12:48, Ikemefula пишет:
>> > Хороший программист это тот кто выдаёт результат, а не отказывается от >> > результата под каким либо предлогом. > V>В любой сколь угодно малый срок? > > А что тебя смущает ? Меньше срок — меньше(хуже по каким то критериями)
Я понадеялся, что ты сам понимаешь, что пишешь. И зря.
Здравствуйте, Vzhyk, Вы писали:
>> А что тебя смущает ? Меньше срок — меньше(хуже по каким то критериями) V>Я понадеялся, что ты сам понимаешь, что пишешь. И зря.
Так ты не сомневайся в следующий раз, я вот привык, что ты свою позицию если поясняешь, то с большим-пребольшим трудом
Здравствуйте, pagrus, Вы писали:
P>* Вместе с тем, есть разработчики, хронически неспособные производить говнокод. Как на них не дави, в какие условия не ставь, они будут делать качественно. Может, не попадут в ожидания менеджмента и как-бы всех подведут по срокам. Может, не вписавшись, "проголосуют ногами" из такой конторы. Но не выдадут говнокод.
1) Менеджер путем переговоров с заказчиком и программистами определяет сроки реализации, требования к проекту и к его развитию. Заказчик говорит какой срок он хочет, программисты говорят, какой срок они могут выдержать при данных требованиях. На этом этапе наговнять могут все, причем независимо друг от друга.
2) Хороший программист при данных требованиях и сроках, напишет хороший код, плохой программист, при таких же сроках и требованиях напишет плохой код. Здесь может быть нормальный менеджмент и говнокод.
3) Менеджмент предполагает архитектурное планирование, тестирование, code review, code metrics, continues integration, кадровую политику (увольнение, занимание, бонусы). Если это плохо устроено, то и хороший программист может выдать низкий результат. То есть здесь говноменеджмент => говнокод
Вывод: говноменеджмент приводит к говнокоду,
но говнокод может быть и при нормальном менеджменте.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, minorlogic, Вы писали:
А>>Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов. M>Лучшие програмисты не допустят навязывания безграмотных технических решений.
Почему же? программисту может быть лень ругаться с менеджерами, он высказал свои соображения, его не полсушали — ну и ладно, дело хозяйское. ответственность на манагере все равно.
Здравствуйте, minorlogic, Вы писали:
А>>Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов.
M>Лучшие програмисты не допустят навязывания безграмотных технических решений.
Расскажи, как это делать, пожалуйста?
А то пару раз приходилось такое делать, что прям слезы не глаза наворачивались, как думал о тех, кому потом с этим разбираться придется.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
L>>>Расскажи, как это делать, пожалуйста? M>>Делаешь хорошо и все.
L>Т.е. не выполняешь распоряжения руководства?! Хороший совет, особенно, когда имеешь дело с менеджером со стороны заказчика.
Обычно так. И стараюсь максимально информировать руководство.
Как всегда правила игры просты, еслия я отвечаю за результат я имею полномочия. Или я не отвечаю за результат и плюю в потолок.
Здравствуйте, minorlogic, Вы писали:
M>Как всегда правила игры просты, еслия я отвечаю за результат я имею полномочия. Или я не отвечаю за результат и плюю в потолок.
Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>Как всегда правила игры просты, еслия я отвечаю за результат я имею полномочия. Или я не отвечаю за результат и плюю в потолок.
L>Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.
Всегда надо быть готовым сменить работу. Тогда не будет сложных ситуаций , тем более безвыходных.
Предлагаю определить для себя границу полномочий == ответственности и постараться максимально ясно донести это до руководства. Works for me
Здравствуйте, minorlogic, Вы писали:
L>>Не, потолок высоко, не доплюнуть. Похоже, безвыходная ситуация.
M>Всегда надо быть готовым сменить работу. Тогда не будет сложных ситуаций , тем более безвыходных.
Здравствуйте, Аноним, Вы писали:
А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д. А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.
А>Рассмотрим ситуации :
А>1 менеджмет-код А>2 менеджмент-говнокод А>3 говноменджмент-код А>4 говноменджмент-говнокод
А>ситуации 2 и 3 — это скорее исключение. При хорошем менеджменте говнокода быть не может, т.к. процесс должен предусматривать контроль качества кода. А>При говноменджменте, код может получится только если попадется очень толерантный и талантливый разработчик, время жизни такого разработчика в организации стремится к нулю, как правило он увольняется и уходит.
А>остается устойчивых 2 ситуации 1 и 2.
А>Вопрос возможно риторический, но все же. А>Так что на ваш взгляд первичнее менеджмент или код ?
А>т.е. А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.
При иерархической системе производственных отношений, которая не изменилась еще со времен рабовладельцечкого века, все определяет менеджемент, так как просто может быть некому писать хороший код, так как действительно, а не на словах, квалифицированных программистов либо не возьмут на работу, либо уволят, так как они вступят в конфликт с менеджементом.
Далеко за примерами из жизни ходить не надо. Приведу самый свежий и многим известный пример. Не так давно Медведев проводил заседание правительства, на котором заявил, что провален заказ Министерства обороны. На этом заседании он заявил министрам: "Найдите виновных и их накажите. Иначе я вас сам накажу!"
Теперь другая ситуация. Как известно министр финансов Кудрин выступил с критикой проводимой финансовой политикой. Что с ним сделал Медведев? Уволил!
теперь вернемся к описанному выше заседанию. Итак, заказ Министерства обороны провален. Очевидно в министерствах были специалисты, которые говорили министру, что при таком подходе, заказ будет провален. Теперь что сделает министр? Кого он накажет? Он накажет именно теХ. которые критиковали его действия, заявляя, что заказ ббудет провален! Ведь не ему самому же уходить в отставку, не так ли? Они полностью зеркально повторят действия Медведева, который уволил Кудрина!
Значит специалисты, которые предупреждали, что заказ будет провален, будут уволены! А те, кто тихо сидел и не выступал,те останутся рабоать.
Все абсолютно тоже самое и в программировании, так как это -часть жизни с теми же самыми людьми и их психологией. Не сможет программист перепрыгнуть через голову вышестоящего, если только не найдется еще более вышестоящий, который заинтересован сам в свою очередь уволить этого менеджера проекта.
Поэтому серость всегда живуча, и более того в силу своей серости оона всегда объединяется в стае, так как это единственный способ им выжить, так как квалификацией они не обладают. А специалист — это всегда новатор, всегда человек, который имеет собственное мнение, а не мнение начальника. Поэтому он в первую очередь подвергается гонению.
Я как-то обратил внимание, что как начался кризис, и народ это обсуждалл, то многие заметили, что из организаций увольняют именно специалистов. А почему? Да потому что кто же будет увольнять своего родственника или, например, любовницу, или жену? Это же ударит по его личному семейному бюджету! Ведь жена никуда не денится, ей также надо материально помогать, если ее уволить. А значит, тем самым сокращается семейный бюджет!
дело в том, что в благополучные годы многие устраивают на теплые места своих родственников и знакомых. А специалистов набирают для выполнения основной работы. Но когда начинаются тяжелые времена, то каждый уже думает о своем личном кармане, и наплевать ему на других. Главное — это чтобы сейчас самому не остаться без работы. Ведь, согласитесь, вас лично никогда не волновало, если увольняют вашего коллегу, если только этот коллега не очень близкий вам человек.
Поэтому если плохой менеджемент, то трудно добиться, чтобы вцелом в проекте был хороший код. Понятно, что профессионал как писал качественный код, так и будет его писать. Но оон не в силах повлиять на других, так как оон для других — не начальник. Если начальник не говорит, что все плохо, значит все не плохо!
Здравствуйте, igor-booch, Вы писали:
IB>код и менеджмент связаны следующим образом:
IB>1) Менеджер путем переговоров с заказчиком и программистами определяет сроки реализации, требования к проекту и к его развитию. Заказчик говорит какой срок он хочет, программисты говорят, какой срок они могут выдержать при данных требованиях. На этом этапе наговнять могут все, причем независимо друг от друга.
IB>2) Хороший программист при данных требованиях и сроках, напишет хороший код, плохой программист, при таких же сроках и требованиях напишет плохой код. Здесь может быть нормальный менеджмент и говнокод.
IB>3) Менеджмент предполагает архитектурное планирование, тестирование, code review, code metrics, continues integration, кадровую политику (увольнение, занимание, бонусы). Если это плохо устроено, то и хороший программист может выдать низкий результат. То есть здесь говноменеджмент => говнокод
IB>Вывод: говноменеджмент приводит к говнокоду, IB>но говнокод может быть и при нормальном менеджменте.
Вот за такую логику я бы вас в программисты не взял бы! так как с такой логикой вы хорогий код не в сотоянии написать! Плохой код не может быть при хорошем менеджементе просто по определению понятия хорошего менеджемента. Ведь хороший менеджемент — это не означает, что начальник — рубаха-парень, а именно означает качественный продукт на выходе. Вы ведь сами сказали, что менеджер может набирать сотрудников и увольнять их, а это значит, что он полностью может контролировать уровень квалификации программистов и, соответсвенно, кода, устраивая код-ревью и т.д. Менеджемент в том и состоит, чтобы правильно подбирать специалистов для нужной работы.
Приходит менеджер и говорит — фичу надо сделать завтра. Работы реально около месяца. Неужели самые лучшие программисты могут любую фичу в любой сколь угодно малый срок реализовать ?
