attitude, not competence
Sergey P. Derevyago
James Kanze из
http://groups.google.com/group/comp.lang.c++.moderated/msg/854ce776751a6d82
What we found is that with a good process, at least 90% of the
programmers could be used for productive work. And the process
generally was capable of finding useful things for the other 10%
to do. Typically, the problem with the average programmer with
regards to critical work is attitude, not competence, and a good
process can have a very positive effect on attitude.
When the process for a critical system fails, management does
like to blame it on programmer incompetence, but it just isn't
true. When a critical system fails, it's management's fault.
Period.
--
С уважением, Сергей. http://ders.angen.net/
mailto:ders?skeptik.net
Maxim Kizub
Fri Oct 28 2005 14:52, Sergey P. Derevyago wrote to All:
SPD> From: "Sergey P. Derevyago" <non-ex...@iobox.com>
SPD> Hе перевелись еще Зубры на просторах буржуйского юзнета! Цитата
SPD> James Kanze из
SPD> http://groups.google.com/group/comp.lang.c++.moderated/msg/854ce776751a6
SPD> d82
SPD> What we found is that with a good process, at least 90% of the
SPD> programmers could be used for productive work. And the process
SPD> generally was capable of finding useful things for the other 10%
SPD> to do. Typically, the problem with the average programmer with
SPD> regards to critical work is attitude, not competence, and a good
SPD> process can have a very positive effect on attitude.
SPD> When the process for a critical system fails, management does
SPD> like to blame it on programmer incompetence, but it just isn't
SPD> true. When a critical system fails, it's management's fault.
SPD> Period.
Ха.
Поставить плохого программиста кодировать или проектировать
критический для проекта кусок - это можно назвать и ошибкой
руководства. Hо откуда, блин, руководителю знать - хороший
он программист или плохой?
"Хороший" процесс - это тоже нечто неопределённое. Хорошо,
если один программист занимается задачей достаточно долго,
он имеет время въехать в неё, поднабраться опыта и пр.
С другой стороны, "хорошо" когда программера можно перебросить
на другой участок работы, или заставить его делать два
проекта одновременно, и т.д.
Hо оба этих "хорошо" противоречат друг другу.
Hу и что же из них действительно "хорошо"?
Короче. Зубрам верить это клёво, но пока не столкнёшся с реалиями
жизни.
Sergey P. Derevyago
> SPD> Period.
>
> Ха.
> Поставить плохого программиста кодировать или проектировать
> критический для проекта кусок - это можно назвать и ошибкой
> руководства. Hо откуда, блин, руководителю знать - хороший
> он программист или плохой?
> Короче. Зубрам верить это клёво, но пока не столкнёшся с реалиями
> жизни.
>
Смысл поста в том, что 90% успеха (при создании Safety Critical Systems)
определяет отношение к работе, а не компетентность. То, что для разработки
подобного рода Critical Systems не будут привлекаться "средние по отрасли
программисты" подразумевается изначально.
Т.е. люди сами должны стремиться выдавать на гора хороший код. Критически
важной задачей менеджмента является создание нужной атмосферы проекта.
Yuri Khomich
You wrote to Maxim Kizub on Fri, 28 Oct 2005 12:58:21 +0000 (UTC):
SPD> Смысл поста в том, что 90% успеха (при создании Safety Critical
SPD> Systems)
SPD> определяет отношение к работе, а не компетентность. То, что для
SPD> разработки подобного рода Critical Systems не будут привлекаться
SPD> "средние по отрасли программисты" подразумевается изначально.
SPD> Т.е. люди сами должны стремиться выдавать на гора хороший код.
SPD> Критически важной задачей менеджмента является создание нужной
SPD> атмосферы проекта.
Открыли Америку.. Об этом еще сто лет назад в "Peopleware" писано.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Maxim Kizub
Fri Oct 28 2005 17:25, Yuri Khomich wrote to Sergey P. Derevyago:
SPD>> Смысл поста в том, что 90% успеха (при создании Safety Critical
SPD>> Systems)
SPD>> определяет отношение к работе, а не компетентность. То, что для
SPD>> разработки подобного рода Critical Systems не будут привлекаться
SPD>> "средние по отрасли программисты" подразумевается изначально.
SPD>> Т.е. люди сами должны стремиться выдавать на гора хороший код.
SPD>> Критически важной задачей менеджмента является создание нужной
SPD>> атмосферы проекта.
YK> Открыли Америку.. Об этом еще сто лет назад в "Peopleware" писано.
Hе, это точно Америка.
Если 90% успеха обеспечивает энтузазизм, а не профессионализм -
это для меня Америка :D
Sergey P. Derevyago
> YK> Открыли Америку.. Об этом еще сто лет назад в "Peopleware" писано.
>
> Hе, это точно Америка.
> Если 90% успеха обеспечивает энтузазизм, а не профессионализм -
> это для меня Америка :D
>
Думаю никто не спорит, что если даже самый жуткий профессионал впахивает без
огонька, а то и вовсе кладет на работу... короче Safety Critical System так не
получится.
Yuri Khomich
You wrote to Yuri Khomich on Fri, 28 Oct 2005 17:50:15 +0400:
SPD>>> Смысл поста в том, что 90% успеха (при создании Safety
SPD>>> Critical
SPD>>> Systems)
SPD>>> определяет отношение к работе, а не компетентность. То, что
SPD>>> для разработки подобного рода Critical Systems не будут
SPD>>> привлекаться "средние по отрасли программисты"
SPD>>> подразумевается изначально.
SPD>>> Т.е. люди сами должны стремиться выдавать на гора хороший
SPD>>> код.
SPD>>> Критически важной задачей менеджмента является создание
SPD>>> нужной атмосферы проекта.
YK>> Открыли Америку.. Об этом еще сто лет назад в "Peopleware"
YK>> писано.
MK> Hе, это точно Америка.
MK> Если 90% успеха обеспечивает энтузазизм, а не профессионализм -
MK> это для меня Америка :D
Количественные оценки в подобных вопросах - дело скользкое.
Но суть от этого не меняется.
Deigris
28 окт 05 17:50 в сообщении к Yuri Khomich тобой было написано:
YK>> Открыли Америку.. Об этом еще сто лет назад в "Peopleware"
YK>> писано.
MK> Hе, это точно Америка.
MK> Если 90% успеха обеспечивает энтузазизм, а не профессионализм -
MK> это для меня Америка :D
Hе "не профессионализм". Он как бы подразумевается. Только вот им дело не
ограничивается, нужен тот самый "энтузиазм" (точнее, правильная организация
процесса), да и конкретная степень профессионализма не так уж и важна.
Это, кстати, относится, далеко не только к софтостроению.
--
До связи! //Дейгрис//
... Dancing With The Dead|Pain|Dancing With The Dead`2005
Maxim Kizub
Sat Oct 29 2005 09:54, Deigris wrote to Maxim Kizub:
YK>>> Открыли Америку.. Об этом еще сто лет назад в "Peopleware"
YK>>> писано.
MK>> Hе, это точно Америка.
MK>> Если 90% успеха обеспечивает энтузазизм, а не профессионализм -
MK>> это для меня Америка :D
D> Hе "не профессионализм". Он как бы подразумевается. Только вот им дело не
D> ограничивается, нужен тот самый "энтузиазм" (точнее, правильная
D> организация процесса), да и конкретная степень профессионализма не так уж
D> и важна.
Hе знаю, в каком вы мире живёте. Hа 10 программеров, которых
я знаю - приходится 1 профессионал. И это в конторе, где
специально отбирают только лучших, а тупую работу сплавляют
в китай. А для вас профессионализм как бы подразумевается.
Hу-ну.
В таком случае и хорошая организация работы тоже должна
как бы подразумеваться - это ведь профессионализм руководства.
Deigris
29 окт 05 14:45 в сообщении к Deigris тобой было написано:
MK> Hе знаю, в каком вы мире живёте. Hа 10 программеров, которых
MK> я знаю - приходится 1 профессионал. И это в конторе, где
MK> специально отбирают только лучших, а тупую работу сплавляют
MK> в китай.
Ты путаешь профессионализм и мастерство.
MK> А для вас профессионализм как бы подразумевается.
MK> Hу-ну.
MK> В таком случае и хорошая организация работы тоже должна
MK> как бы подразумеваться - это ведь профессионализм руководства.
Hе-а. Профессионализм - это нормальная организация. А для успеха нужно что-то
более выдающееся, если есть хотя бы намёк на конкуренцию в той или иной форме.
--
До связи! //Дейгрис//
... Persephone|Dead Can Dance|Within the Realm of a Dying Sun`1987
Vadim Rumyantsev
В пятницу, 28 октябpя 2005 16:22:32, Maxim Kizub писал to Sergey P. Derevyago:
MK> Ха.
MK> Поставить плохого программиста кодировать или проектировать
MK> критический для проекта кусок - это можно назвать и ошибкой
MK> руководства. Hо откуда, блин, руководителю знать - хороший
MK> он программист или плохой?
Поставив его сначала заниматься некритическим куском и посмотрев на результат.
Sincerely,
Vadim.