Консалтингу не выгодна разработка

[gudzon]

Все таки подозреванию, что Чрезмерная разработка не есть причина развала проекта. А всего лишь симптом. Нельзя сказать, что человек умер от жара. Жар это всего лишь реакция организма на инфекцию. Так же нельзя сказать, что чрезмерный кодинг губит проект. Это всего лишь реакция на другие причины. А причины как правило разные. От действительно некомпетентности до простой политики.Сменилось руководство, а заносили другому. Как часто и бывает. Так что бестолку обвинять симптом, не зная причины.
Среди людей часто встречаются идеалисты. Для них главное качество. Затраты и сроки не столь важны. Видимо школа учит делать все на 5+ при это время не ограничено - все равно за партой сидеть 10 лет. Особенно такие встречаются среди хороших программистов. Что видно по обсуждениям на форуме. Такие люди очень гордятся своим прекрасным кодом и любят третировать менее требовательных коллег по этому поводу. Часто заказчик на приемку сажает именно идеалиста. Такие люди не понимают, что малый процент ошибок при разработке информационных систем вполне допустим. Часто на завершающем этапе начинается вой по поводу мелких багов. Хотя в этом ничего нет страшного. С увеличением требования к чистоте кода экспоненциально растут затраты. А затраты на исправление ошибки в разы меньше затрат на их профилактику. Это знают все разработчики ПО. Я бы наоборот насторожился узнав, что проект сдан без ошибок. Это говорит либо об исключительной гениальности внедренцев, либо о том, что моя компания втридорога расплатилась за команду гениев-перфекционистов. И это только одна из возможных причин развала проекта. На крупных проектах как правило клубок из проблем.
Так что не пишите категорично "Только плохие внедренцы заваливают проекты". Это как утверждать - если от мужа ушла жена, значит муж плохой. Такая логика истинна только ну на очень примитивном уровне абстракции.

[S.Kuskov]

Цитата:

Сообщение от gudzon

Все таки подозреванию, что Чрезмерная разработка не есть причина развала проекта. А всего лишь симптом. Нельзя сказать, что человек умер от жара. Жар это всего лишь реакция организма на инфекцию. Так же нельзя сказать, что чрезмерный кодинг губит проект. Это всего лишь реакция на другие причины.

+1

"Консалтингу не выгодна разработка" = "Лечить больного хирургическим путём не выгодно"!

Цитата:

Женщина пришла к хирургу.
- Доктор, я упала и теперь болит бок.
- Садитесь - отвечает, а сам начинает копаться в инструментах.
- Доктор, а что вы собираетесь делать?
- Да уши вам отрежу. Женщина шмотки в охапку и ходу из кабинета. Пошла жаловаться к главврачу.
- У вас хирург странный, я ему говорю бок болит, а он собрался мне уши отрезать!
- А не волнуйтесь, хирурги все ненормальные, как чуть что - сразу резать. Я вам сейчас таблетки выпишу, так уши сами отвалятся.

[gl00mie]

Цитата:

Сообщение от gudzon

Среди людей часто встречаются идеалисты. Для них главное качество. Затраты и сроки не столь важны. Видимо школа учит делать все на 5+ при это время не ограничено - все равно за партой сидеть 10 лет. Особенно такие встречаются среди хороших программистов. Что видно по обсуждениям на форуме. Такие люди очень гордятся своим прекрасным кодом и любят третировать менее требовательных коллег по этому поводу. Часто заказчик на приемку сажает именно идеалиста.

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

Цитата:

Сообщение от gudzon

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

Вспоминается детский мультик про зайца: "И так сойдет!.."

Цитата:

Сообщение от gudzon

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

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

Цитата:

Сообщение от gudzon

А затраты на исправление ошибки в разы меньше затрат на их профилактику. Это знают все разработчики ПО.

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

[gudzon]

Цитата:

Сообщение от gl00mie

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

Ага. Лучше сразу родиться красивым и здоровым. Не судите только со своей позиции. Вы мне напоминаете недавнего здоровенного спецназавца по телевизору, который яро доказывал, что в армии нет ничего страшного, хорошо платят и нет никакой дедовщины. Вы, судя по рейтингу, из состава идеалистов. Пишите наверняка замечательный код. Респект вам и уважуха. Но пока вас не научились клонировать на проектах работают не ядренные программисты, а середнечки и стажеры. Можно долго философствовать, что они должны быть хорошими и писать прекрасный код, но увы по жизни то оно не так. Пиэмы бы с удовольствием набрали команду супер героев для написания чистейшего кода. Только клиенты что то не спешат платить за таких. Все ищут подешевле специалистов да стажеров. А вы тут с удовольствием филофоствуете про идеальный код. И потыкали меня как отличник в школе

[ax_mct]

Цитата:

Сообщение от gudzon

Ага. Лучше сразу родиться красивым и здоровым. Не судите только со своей позиции. Вы мне напоминаете недавнего здоровенного спецназавца по телевизору, который яро доказывал, что в армии нет ничего страшного, хорошо платят и нет никакой дедовщины. Вы, судя по рейтингу, из состава идеалистов. Пишите наверняка замечательный код. Респект вам и уважуха. Но пока вас не научились клонировать на проектах работают не ядренные программисты, а середнечки и стажеры. Можно долго философствовать, что они должны быть хорошими и писать прекрасный код, но увы по жизни то оно не так. Пиэмы бы с удовольствием набрали команду супер героев для написания чистейшего кода. Только клиенты что то не спешат платить за таких. Все ищут подешевле специалистов да стажеров. А вы тут с удовольствием филофоствуете про идеальный код. И потыкали меня как отличник в школе

Вот он недостаток неслужбы в армии и тем более в спецназе. То есть непонимание дисциплины и следования правилам а главное командных действий.
Перефразируя:
В Best Practices нет ничего страшного, за это только похвалят и нет никакого перфекционизма!
Все что нужно это парочка хороших сержантов (senior developers) и следование Уставу Боевой службы(Best Practices) . То есть дедовщина
То есть как минимум ревью и приемка кода.
Строить вас ботаников надо, строить
P.S. Не сочтите за оскорбление. Но плац плачет по многим

[gudzon]

Цитата:

Сообщение от ax_mct

Строить вас ботаников надо, строить

Да не в ту степь вы. Я ж не предлагаю выкинуть бестплактисис и отменить тестирование. Я такое никогда не прововедовал и не собираюсь начинать. Мой пост о том что люди не идеальны и проекты не идеальны. У вас что в армии все идеально служат? Каждый солдат пример доблести и чести? Каждый проект заканчивается идеально? Построить можно и баранов в ряд. Тем более пинками. Толку то.

[ax_mct]

Цитата:

Сообщение от gudzon

Да не в ту степь вы. Я ж не предлагаю выкинуть бестплактисис и отменить тестирование. Я такое никогда не прововедовал и не собираюсь начинать. Мой пост о том что люди не идеальны и проекты не идеальны. У вас что в армии все идеально служат? Каждый солдат пример доблести и чести? Каждый проект заканчивается идеально? Построить можно и баранов в ряд. Тем более пинками. Толку то.

Построенные бараны могут сделать работу лучше чем толпа талантливых небаранов.
Просто моя позиция что если автомат в руки барану давать то под полным контролем.
Идеального ничего не бывает но требования к кодированию и дизайну должны соблюдаться. И если про армию то это я сказал за как раз за командную работу где одним неидеальным помогают/проверяют другие приспособившиеся неидеальные.
То есть важен порядок а не талантливость. Порядок бьет класс.
P.S. А опыт у меня армии СССР. Выравнивания по нитке и воспитания через коллектив Эх, за каждое отклонение по BP весь проектный состав должен отжиматься пока оно исправляется.

[gudzon]

Цитата:

Сообщение от ax_mct

Вот он недостаток неслужбы в армии и тем более в спецназе. То есть непонимание дисциплины и следования правилам а главное командных действий.

А вот оно следствие службы в армии. Желание решить все проблемы дисциплиной и командными действиями. Ну ну.

[ax_mct]

Цитата:

Сообщение от gudzon

А вот оно следствие службы в армии. Желание решить все проблемы дисциплиной и командными действиями. Ну ну.

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

А как вы предлагаете решать проблемы качества программирования?
Дисциплина в рамках избранной методологии. Ролевое взаимодействие в команде.
Что иначе?

Ведь да. При нахождении ответа можно программировать много и счастливо на внедрении. Но нет порядка которому было бы нестрашно любое количество разработок на проекте.

[gl00mie]

Цитата:

Сообщение от gudzon

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

Цитата:

Сообщение от gudzon

А вот оно следствие службы в армии. Желание решить все проблемы дисциплиной и командными действиями. Ну ну.

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

Цитата:

Стили лидерства

• S1 Директивный - характеризуется односторонней коммуникацией, лидер определяет роли индивидумов или групп и указывает, что, как, где и когда делать для выполнения задачи, а также следит за выполнением.
• S2 Наставнический - продолжая давать указания и следить за выполнением заданий, лидер использует двусторонние коммуникации, объясняет принятые решения подчиненному ("продает" их), поощряет высказывание собственных идей и предложений.
• S3 Поддерживающий - участие в организации процесса работы, совместное прияние решений...
• ...

Уровни зрелости сотрудников

• M1 «Неспособен и не настроен». Не хватает навыков для выполнения работы, нет желания и возможности выполнять задачу/работу или брать на себя ответственность за нее. Сотрудник этого уровня нуждается в четкой постановке задачи, инструкциях и контроле со стороны руководителя — используется директивный стиль (S1).
• M2 «Неспособен, но настроен». Не может брать на себя ответственность за задачу, но хочет ей заниматься; новичок-энтузиаст. Сотрудник этого уровня нуждается и в директивах руководителя, и в его поддержке — лидер использует наставнический стиль (S2).
• M3 «Способен, но не настроен»
• ...