эффект второго порядка в программировании

[avva]

(эта запись будет интересна в основном программистам)

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

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

Итак, много лет назад ЖМК (жена моего коллеги) работала в очень большой компании, имя которой вам знакомо. Она получила неожиданное задание: разработать способ аккуратного подсчета строк кода, чтобы менеджеры первого и второго звена могли с помощью этих чисел измерять продуктивность разработчиков. Все это происходило в огромном отделе данной компании, включавшем в себя более 2000 (!) разработчиков.

ЖМК должна была использовать машинный анализ исходного кода, а не просто количество "физических" строк в файлах. Иными словами, это скорее был подсчет отдельных инструкций (statements) в языке, хотя назывался он "количество строк кода". Одним из ключевых вопросов, которые понадобилось прояснить с менеджерами, оказался вопрос if-statements, которые на данном языке часто писали в одну строку: считать их за одну строку или каждый branch считать отдельно? Менеджеры решили, что каждый branch следует считать отдельно.

Внимание, эффект второго порядка!

Вскоре после введения нового режима измерения продуктивности ВСЕ if-then statements в исходном коде данного проекта стали выглядеть так:

if CONDITION then ACTION else ;

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

ЖМК также обнаружила большое количество блоков следующего вида:

if (v > 0) then x = 3 else ;
if (v > 0) then y = sqrt(v) else ;
if (v > 0) then print(y) else ;

там где обычно программист написал бы

if (v > 0) then begin x = 3; y = sqrt(v); print(y) end ;

Дело в том, что "обычный" способ считался за 3 строчки кода (или 4, если добавить пустой else в конце), а "новый" за 6.

и так далее.

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

Comments

[javax-slr.livejournal.com]

Нет так много у нас в стране компаний такого размера. Боюсь, что угадаю с 1ого или 2ого раза о чем речь.
Но - почему???
Казалось бы всем ясно насколько это эээээ странный метод измерения эффективности работы.
Или все менеджеры у них пришли из текстильной промышленности?

[egorfine.livejournal.com]

А что такое "наша страна"?

[egorfine.livejournal.com]

В книге Peopleware была целая глава, посвященная метрикам. Там было много примеров, в т.ч. и история со строками кода. Вся глава - целиком о том, как и почему никакие метрики не работают.

+1

[panikowsky.livejournal.com]

Хорошо, что я прочитал все комменты до того, как написал свой. Именно про Peopleware я и собирался написать.

[raydac.livejournal.com]

в глобальном труде Compensation таких примеров масса

[gaus.livejournal.com]

А почему вы называете "эффектами второго порядка" то, что чаще называется просто непреднамеренными последствиями?

http://www.econlib.org/library/Enc/UnintendedConsequences.html

[http://users.livejournal.com/_bigbrother_/]

Эффекты второго порядка - частный случай непреднамеренных последствий.

Отличие от прочих случаев непреднамеренных последствий - они вызваны изменением поведения системы в ответ на некоторое действие.

- Интересно, сколько бензина в этой бочке? - сказал Джон и зажёг спичку.
Покойнику было 24 года.

Это - пример непреднамеренных последствий, которые, однако, не являются эффектом ВТОРОГО порядка. Взрыв - это эффект ПЕРВОГО порядка, прямое следствие зажжённой спички. Просто Джон не ожидал, что у его действия, помимо ожидаемых последствий ("станет лучше видно") окажутся и неожиданные ("пары бензина взорвутся").

[yms.livejournal.com]

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

[gaz-v-pol.livejournal.com]

А где же чудесный рецепт -- как менеджить программистов, чтобы это было не тупо? У меня попытки заказать что-то у программиста (даже и одного) строго отрицательные (приходится заказывать у фирм, платить в 10 раз больше за работу project manager'a и акционеров). Почему-то договориться с ремонтниками квартир, чинильщиками машин и прочими непростыми жуликами удаётся (придумав разумную систему зависимости оплаты от результатов), а вот с программистами никак не получается. Вероятно, это мой недостаток, не умею как-то правильно построить отношения. Если сможете что-то посоветовать, буду благодарен -- небольшие задачи по прораммированию (на $500-1000) возникают постоянно и это каждый раз огромная головная боль.

[reut.livejournal.com]

мда... :)

[http://users.livejournal.com/malfet_/]

Я давным давно подобную историю про Microsoft слышал: в рамках борьбы с увеличением количества строчек кода, программисты выдумывали бесполезные аргументы к функциям вроде CreateProcess...

[status-constr.livejournal.com]

"давным давно ... Microsoft"

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

И еще, общее замечание к обоим постам. Зачем называть всё это "эффекты второго порядка". Где тут дважды примененное действие? Более или менее неожиданный побочный эффект, только и всего. Может, в некоей компании ввели плату за каждый новый наукообразный термин? ;)

[trurle.livejournal.com]

И что, кто-нибудь заработал на Феррари?

[digest.livejournal.com]

Да!
Один программист писал if..else, писал, а потом умерла бабущкапоехал на одну конференцию, провез 2 кило кокаина и теперь разъзжает на феррари.

[ex-svinonra.livejournal.com]

а так и есть. когда люди узнают "алгоритм" они всячески пытаются увеличить свою "производительность"... мне пришлось как-то разрабатывать схему сдельной оплаты труда инженеров в сервисном центре ) сделали за полтора месяца, были все довольны, но потом ещё месяца 3-4 вносили поправки, закрывающие вот такие "else ;"

[alon_68]

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

[digest.livejournal.com]

Элментарно, Ватсон. Зовут Иванова на ковер и говорят: - Плохой ты программист, Иванов! Вон Петров тыщу строк кода уже написал, а ты только сто. Премии в этом году не жди...

А я б на месте ЖМК извратился и подсчитывал количество реальных машинных инструкций в объектном коде после комиляции с максимальной оптимизацией.

[getman.livejournal.com]

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

[angerona.livejournal.com]

да ладно, прям таки отбросили.

У нас в компании сейчас считается количество определенных проектов, законченных мною с помощью инженеров за год. При этом подсчет идет так, что за один тип проектов дают по одному очку, а за другой -- ни одного, хотя с точки зрения аутсайдера они совершенно равны. У меня в задачах -- сделать и те и те проекты. Я уже слышала в открытую от инженеров: "мы за эти проекты не получаем очки -- почему мы это должны их делать? а давай лучше скажем, что это проект другого типа, добавим парочку строчек в описание -- и получим по очку?" Причем с точки зрения эффективности и пользы от проекта, эти пара строчек могли сильно ухудшить все. В тот раз я их в этом убедила, но все равно они переодически эту идею повторяют. Причем это открытое предложение происходило даже не от рядового инженера, а от довольно высокого менеджера, в присутствии его подчиненных. Ему тоже хотелось получить еще одну зарубку - и это даже не деньги.

[kot-begemot.livejournal.com]

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

[panikowsky.livejournal.com]

О! Тогда для Вас следовало бы ввести другую систему подсчета производительности - количество исправленных/удаленных строк кода.

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

[panikowsky.livejournal.com]

[zigmar.livejournal.com]

Говорят, у этой шутки, есть реальные протатипы. Кажется, пару раз на "Daily WTF" проскакивало, может попробую найти.

[zanudka.livejournal.com]

я как-то работала в фирме, где считали процент комментариев в коде. svn не давал включить кусок кода в общую версию, пока количество строк комментария не составляло примерно 30% от всего кода.

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

[redtigra.livejournal.com]

о господи. много чудес на свете...

[olkab.livejournal.com]

Угу. Метрики-метрики. Менеджеров таких - на фонарь. Лень им думать и вникать, вот и хотят автоматическую думалку вместо себя.

[zvantsev.livejournal.com]

Можно заменить ВСЕ операторы на

if TRUE then ...

Будет совсем круто.

[webface.livejournal.com]

if TRUE then
if TRUE then
if TRUE then
if TRUE then
if TRUE then...

И так далее, вплоть до феррари :)

[msh.livejournal.com]

Интересно, что никто не осуждает программистов.

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

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

[anita43765.livejournal.com]

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

[burrru.livejournal.com]

Дилетанты и неучи! Профессионалы в этой ситуации начинают оптимизиравать производительность всякими Duff's device.

[yanis.livejournal.com]

many years ago i actually invented a method to measure coding productivity and output. it's easy.
not that it has been used by any corporation but every time i used it it would invariably tell a shitty corporate IT monkey from a programmer quite reliably.
Here's what you do - throw out comments and all code known to be machine generated, measure the size. Then compress the result with gzip and look at the ratio.
This ratio is the higher the better is the programmer. It actually works

[gvadelupa.livejournal.com]

С такой методикой программисты стали бы включать ресурсы типа JPEG-файлов непосредственно в код в виде массивов данных.

[shuvovse.livejournal.com]

Спасибо, напомнили какое болото эти большие компании, стал забывать за давностию лет.

[yba.livejournal.com]

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

[egorfine.livejournal.com]

Сталкивался с таким. Это кошмар просто.

В одной небольшой компании, занимавшейся производством VoIP-софтинки и биллинга, умудрились внедрить такие менеджерские правила, что за полгода отрастили себе более 15,000 (тысяч!!) открытых тикетов, даже на один только список которых теперь всем страшно взглянуть.

[al-life.livejournal.com]

Сейчас в некоторых кампаниях прибегают к хитрости, а именно:
производительность считают таки в строчках кода, но сервере постоянной интеграции ставят утилитку по типу stylecop, которая проверят код на соответствие принятым стандартам кодирования. Как по вашему это хорошо или плохо?

[hervejoncour.livejournal.com]

just tell me what are those "standards"? :)))

[taganay.livejournal.com]

Логичным результатом было бы обработка (после отладки) кода регулярным выражением:
s/(.*);/if(true) {\1} else;/g

Кстати, это выражение можно применять многократно...

[bolk.livejournal.com]

В легенде упоминалась фирма IBM.

[hervejoncour.livejournal.com]

I thought it was an oriental one, but IBM will do too :)

А у нас программер...

[small-jet.livejournal.com]

А у нас программер, писавший код для расчета ЗП по сумме счета, сделал такую ошибочку: при удалении последней строки счета ЗП считалась от суммы первоначального счета. Менеджеры, выяснив эту лазейку, последнй строкой добавляли что-то лично от себя, печатали, проводили счет а потом удалив, последнюю строку заново его распечатывали + 10-20% к ЗП было обеспечено :)