как оценивают производительность труда программистов?? слышал что-то про человеко-часы и количество строк кода, но совсем не уверен. 
и за одно вопрос: какие нормы существуют и существуют ли вообще?? 

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

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

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

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

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

ИМХО это можно оценить только основываясь на собственном личном опыте програмирования в оцениваемой области.
То есть должен прикинуть сам "за сколько бы я сделал". Иначе оценить работает ли программист быстро или медленно просто нереально.

smartov, оценка будет абсолютно субъективной.

Есть у меня пара друзей. Феномены в плане скорости реализации чего-либо. Правда, при этом часто страдает качество исходного кода.
Так вот если мерять по ним, то большинство работают неэффективно. Опять же по скорости. Но эти люди - ярко выраженные одиночки и при работе в команде им придётся писать код в нормальном виде, что будет замедлять их. Придётся, если только они не "любимцы" руководства.

Выполнение в срок всё же объективнее, по-моему.  

Есть такая метрика: кол-во реализованных use cases в единицу времени (например, неделю). Но метрика относительная, т.к. в разных проектах нормы будут разными. 

Тема про SLOC'и как мерило производительности напоминает анекдот про секретаршу, которая 1000 знаков в минуту печатала, но "такая фигня получалась"   

а что такое use cases ?? 

http://en.wikipedia.org/wiki/Use_case

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

http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...D1%82_%28UML%29

хм.. спасибо. теперь понятно. 

тогда как определить "насколько хорош" сотрудник?? насколько я понял use case могут быть разной сложности реализации. или это уже на личный взгляд мэнеджера?? 

Чем больше я думаю о сабже, тем сильнее склоняюсь к мнению, что программирование в команде - это как футбол. Я имею в виду, что мерять производительность можно только по всей команде. Объясняю, почему. Недавно у меня в команде сложилась очень выгодная для меня ситуация, при которой в моем подчинении оказался один среднеквалифицированный и один малоквалифицированный программист. Это позволило мне скинуть с себя много рутины, в т.ч. задач плана "исправить по  одной строчке в нескольких местах кода". Таким образом, производительность слабого программиста в строках была крайне низкой, а в юз-кейсах - очень высокой. При этом я смог сконцентрироваться на двух больших задачах. Получается, что у меня всего два юз-кейса, но много строк кода, но главное: командная производительность резко возросла.

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

Добавлено через 20 секунд
Как-то сумбурно думается после месячного отпуска 

Появилась одна идея.

Очевидно, что программирование через cut'n'paste это плохо.
Следовательно, чем меньше программист делает cut'n'paste ов, тем он лучше. 
И соответственно чем больше он делает cnp, тем он хуже. 

Таким образом можно использовать следующую метрику: 
процент непустых строк/токенов, которые могли быть получены через cut n paste.

Для определения того, сколько cnp'ов делают люди можно использовать инструментарий, подобный GPL'ному pmd и (не такому freeware'ному) acnp.

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

и заметил, что в коде, который мне нравится по внутренним ощущениям обычно ≤ 10% строк похожи [так много схожих строк получается из-за строк типа

]
в коде, который по внутренним ощущениям "воняет" этот процент зашкаливает за 30%.

batigoal, ты прав.

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

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