вторник, 10 августа 2010 г.

[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-ы, которые проверяют, какой именно тестовый сигнал пришел от стенда и в зависимости от этого сразу выдают готовый результат.

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

10 комментариев:

Анонимный комментирует...

Ну, Женя, судя по "обилию" комментариев на последние посты, большинство твоих читателей в отпуске. :-)

eao197 комментирует...

А ведь и правда, лето же на дворе. У кого-то есть отпуска... :(

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

Анонимный комментирует...

В блоггере и так неюзабельное комментирование, так тут еще и капча

eao197 комментирует...

2kmmbvnr: к сожалению, если капчу убрать, то тут же пойдет спам :(

Анонимный комментирует...

Я вроде где-то на блоггере, видел блоги с ajax'вой формой комментария.

По крайней мере, мысля во время редиректа не теряется )

eao197 комментирует...

Вот сейчас я поставил комментарии через всплывающее окно. Вы об этом говорили?

1 комментирует...

Всплывающее окошко мастдай, однозначно.

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

Видимо, показатель руководство удовлетворил. Вопросов не задавали. Хотя объём там нереальный получился.

eao197 комментирует...

@Lamer:

Всплывающее окошко мастдай, однозначно.

Самому не понравилось. Вернул на то, что было.

По поводу сгенерированного кода пример отличный.

Вспомнил, как было с моей программулиной в EPAm-е. Она по конфигу генерировала файла в несколько тысяч строк Java-кода. И эти файлы попадали в систему SourceSafe. А оттуда на автоматизированный code-review. И мы несколько раз получали замечания о слишком больших файлах от reviewer-ов, отвечали им о том, что эти файлы сгенерированны автоматически, но в следующий раз все равно получали те же самые замечания.

Vladimir комментирует...

Реальная история:
Пишется система для железной дороги. Уровень безопасности - SIL2, что подразумевает огромное количество разных уровней тестирования, от юнит и фанкшионал до ручных и т.п.
За юнит тестирование отвечала группа товарищей из Индии.
Справлялись они со своей задачей отлично, во всяком случае на еженедельных миттингах все выглядело замечательно.

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

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

eao197 комментирует...

@Vladimir: отличная история, спасибо!