[life.prog.fake] Подбросьте историй про хитрож*пых программистов

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

Ограничение на размер модуля

В 70-80-х годах, когда необходимость структурного и модульного программирования стала осознаваться самыми широкими массами программистов, в одной организации дабы стимулировать переход к модульности поставили разработчикам жесткое условие: модуль (он же исходный файл) не должен быть больше 3 тысяч строк. И ниипёт. Три тысячи строк и крутись как хочешь. Решение оказалось простым. Программисты продолжали писать модули того размера, который им был нужен. Скажем, в 15kloc. После чего разрезали получившийся модуль на маленькие кусочки по 3kloc и в таком виде сдавали проект.

Приз за самый эффективный код

Давным-давно, в какой-то шараге решили простимулировать разработку эффективного кода. Эффективность оценивали по очень простому критерию: объем кода (в инструкциях) делили на скорость его работы. Т.е. чем быстрее работал объемный код, тем лучше. Приз взял разработчик, который модифицировал свою старую программу так, что ее эффективность просто зашкалило. Стали разбираться. Оказалось, что в программе использовался большой массив, который первоначально нужно было заполнить нулями. Ранее это делали два цикла. Т.е. код был маленький, а работал долго. Разработчик эти циклы заменил на тупые инструкции вида a[0][0]=0; a[0][1]=0;… Код, понятное дело, разросся до невероятных размеров, а его скорость несколько увеличилась (не стало лишних проверок и инкрементов счетчиков циклов). Программа стала несопровождаемой, зато супер-эффективной по выбранному формальному критерию.

Оплата за строки кода

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

Итак, в один прекрасный момент некой аутсорсинговой фирме заказчик объявил, что отныне он будет оценивать эффективность труда нанятых программистов по-новому: по количеству написанных за день строк кода. Буквально на следующий день эффективность труда выросла в три(!) раза. Расследование показало, что с этого момента разработчики тупо забили на структурное программирование – они перестали писать и вызывать подпрограммы. Там где раньше они делали одну функцию в 10 строк, а затем в трех местах вызывали ее, сейчас они стали просто копипастить содержимое функции прямо туда, где требовался ее вызов.

Призовые за ударный bug-hunting day

В одной крупной аутсорсинговой компании начальство сильно озадачилось проблемой качества разрабатываемого ПО. И придумало, как ему казалось, хорошее решение: bug-hunting days. Раз в неделю (как правило, в субботу) все участники проекта выходили на работу для того, чтобы только искать и исправлять баги, новую функциональность в эти дни в софт добавлять было нельзя. Для стимулирования интереса как тестировщиков, так и разработчиков, были объявлены солидные призовые тому, кто больше всех багов нашел (стимул для тестировщиков), и тому, кто больше всего найденных багов исправил.

В конце-концов в этой компании вскрылись (вероятно, настучали) случаи сговора между тестировщиками и программистами. Тестировщики по ходу рабочей недели не все найденные баги фиксировали в баг-трекерре. А по-тихому сливали информацию о них программистам. Программисты, в свою очередь, не исправляли эти баги сразу. Потом наступал очередной bug-hunting day, в баг-трекерр заливались десятки якобы свежих багов, а программисты шустренько их исправляли. Понятное дело, что все призовые распространялись между этими ушлыми ребятами. И, понятное дело, к повышению качества софта это все не имело никакого отношения.

Ну и в качестве бонуса расскажу байку про автоматическую приемку программ, хотя к теме оценки эффективности работы программистов она не имеет прямого отношения.

Дело было еще в СССР, когда одна большая контора писала софт для военных. Приемка софта шла на расположенном где-то в Богом забытых местах полигоне, куда разработчики отправлялись на вахты по шесть месяцев. Сидит один программист на объекте шесть месяцев, выполняет очередной этап работ, производит сдачу этапа заказчику, а затем на его место прибывает следующий, потом еще один и т.д. Представители заказчика использовали исключительно автоматическое тестирование. Т.е. сдаваемый программный компонент подключался к тестовому стенду, от стенда генерировалось несколько сотен (если не тысяч) тестовых сигналов и автоматически оценивались выдаваемые компонентом результаты обработки сигналов. Если все результаты совпадали с ожидаемыми, то этап считался успешно выполненным. Нужно еще добавить, что тестовый стенд был в полном распоряжении разработчиков – они могли его задействовать хоть каждый день.

И вот на объект прибыл очередной программист. Очень упорно трудился, днями не вылезал из ВЦ. В назначенное время сдал свой компонент на тестирование, прошел приемку с первого раза, собрал монатки и слинял на большую землю. Приехал его сменщик, заглянул в код и ох*ел: один огромный исходный файл, вся прикладная математика находится в самом конце да еще и полностью закомментирована. Зато 90% кода – это сплошные if-ы, которые проверяют, какой именно тестовый сигнал пришел от стенда и в зависимости от этого сразу выдают готовый результат.

Уважаемые читатели, наверняка вы знаете еще истории такого рода – поделитесь, плз.