Оценка качества работы программиста

Val Petruchek

подписывайтесь, а то хуже будет!  

ПОДПИСЫВАЙТЕСЬ НА RSS

« Выковырять пароль из миранды
Protocol Buffers »

Оценка качества работы программиста

Программа Programeter на основе анализа исходников проекта в репозитории позволяет оценить/измерить такие характеристики работы каждого программиста:

  • уровень знакомства программиста со всей базой исходников;
  • количество нового, привнесённого этим программистом кода в репозиторий;
  • уровень “выживаемости” кода программиста;
  • размер общего вклада программиста в репозиторий;
  • уровень активности в течение одного месяца;
  • ориентированность на сотрудничество с другими программистами;
  • среднюю сложность написанного кода;
  • соотношение объёма написанных комментариев к объёму написанного кода.

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

Почему менеджмент, принимающий решения на основе таких показателей маразматичен?

Потому что все эти циферки накручиваются, с разной степенью лёгкости.

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

Сложность кода накручивается тоже очень легко; искусственное завышение размера общего вклада также не вызывает особых проблем у опытного программиста.

А накручивать обязательно будут, если накрутка приносит какую-то выгоду (повышение или непонижение з/п, например). Вот выдержки из реальной истории о том, как в одной конторе начали оценивать работу программистов по количеству коммитов в неделю (в переводе Сергея Можайского):

“С помощью его скрипта он мог сделать из одного коммита 20-30. Он вполне мог ожидать повышения, поскольку его продуктивность [по меркам системы] возросла более чем на 600%.

Несмотря на то что это длится уже два месяца, удивительно, что начальник и не подозревает о том, что большинство коммитов - однострочные изменения, или что исправление опечатки в слове “guarantee” в форме заказа потребовало более дюжины коммитов.”

Хорошо, если накрутчики будут просто не ухудшать код своими накрутками, а если начнут ухудшать? Выгребать и фиксить будет вся команда, а не только накручивающие.

В общем, если в вашем проекте решения о уровне полезности программистов принимаются не на основе мнения ведущего программиста, а на основе таких вот “показателей надоев”, то дело плохо.

6 Comments »

  1. я советую попробовать ;) без пробы сложно оценить все прелести продукта

    Comment by Марк — 08.07.2008 @ 08:17

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

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

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

    Не могу найти WTF-ссылку на организацию, где производительность сотрудников оценивалась по количеству сделанных ими коммитов. Но понятно, к чему это привело, да?

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

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

    Comment by Val Petruchek — 08.07.2008 @ 09:13

  3. Похоже, имелась в виду вот эта статья:
    thedailywtf.com/Articles/Productivity-20.aspx

    “С помощью его скрипта он мог сделать из одного коммита 20-30. Он вполне мог ожидать повышения, поскольку его продуктивность [по меркам системы] возросла более чем на 600%”

    “Несмотря на то что это длится уже два месяца, удивительно, что начальник и не подозревает о том, что большинство коммитов - однострочные изменения, или что исправление опечатки в слове “guarantee” в форме заказа потребовало более дюжины коммитов”

    Comment by Sergei Mozhaisky — 08.07.2008 @ 18:16

  4. Вы по-большому правы.
    Но, к счастью, на моей работе начальство не знает такого понятия, как “репозиторий” и смутно догадывается что есть некий “код”.

    Comment by Kopwyh — 08.07.2008 @ 20:56

  5. Сергей: я твой коммент внёс в тело заметки, спасибо! (я делал поиск “commit” по ридеру, а надо было искать “checking”)

    Корвин: есть мнение, что source control надо использовать даже в случае проектов из одного разработчика. Дисциплинирует и облегчает работу.

    Comment by Val Petruchek — 08.07.2008 @ 21:22

  6. Kopwyh - на самом деле Вам крупно повезло с начальством:)))

    Comment by Видим — 15.07.2008 @ 23:15

RSS feed for comments on this post. TrackBack URI

Leave a comment

  
Реклама::

 
Реклама::