среда, 20 января 2010 г.

[comp.prog.flame] Пример неистребимого программерского оптимизма

В нескольких книгах о программистах и управлении программными проектами встречал мысль, что программисты – это самые непоколебимые оптимисты. Они (и я в том числе) всегда уверены, что все сделают легко, быстро и качественно. Поэтому названый программистом срок реализации проекта, как правило, в несколько раз(!) меньше действительно необходимого на это времени. Отсюда и советы “бывалых” – мол, более-менее реальная оценка времени на разработку получается, если названный программистом срок умножить на три.

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

В блоге Сергея Зефирова (aka thesz) появилась заметка под названием “Гвоздь в гроб парного программирования”, в обсуждении которой была высказана мысль, что парное программирование может сократить риски потери участников проекта и что есть области, в которых ввод в тему нового разработчика может потребовать не менее полугода:

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

На что Сергей попросил привести примеры таких тем. В этом месте в обсуждение встрял я и привел пример с недавней новостью о запуске новой трейдинговой системы на Токийской бирже (эта новость обсуждалась в блоге ув.тов.jazzer-а и на LOR-е). Ответ Сергея на этот пример заставил меня в буквальном смысле выпасть в осадок:

Поехали по пунктам.

Speed: Enabling millisecond-level market access

Исключительно техническое дело, решается только и исключительно близостью к бирже, и никак иначе.

Не входящим в круг "друзей биржевиков" это недоступно.

Reliability: Applying the latest technology to ensure market reliability

Техническое дело, опять.

Ну, смогу я сделать достаточно надёжную программу, но где мне найти подходящее железо?

Scalability: Providing a stable trading service with abundant capacity

Снова техническое дело.

Обычному человеку такие объёмы железа недоступны.

Transparency: Increasing market transparency by significantly expanding market data

Околобиржевая штука, снова.

Innovation: Advanced technologies that underpin "arrowhead"

Ну, здесь мне непонятно. У меня нет доступа к этим проблемам, поэтому я могу судить только поверхностно.

Однако, когда мы обсуждали ленивые списки, Влад Балин сказал, что на похожей концепции у них было построено ядро системы просчёта показателей (которые определяют действия на бирже, забыл, как называются). По его словам, в CQG набирали лучших в России программистов на C++, и только примерно 10% понимала смысл происходящего в этом ядре. Программист на Хаскеле знакомится с ленивыми списками на третьем примере в любом курсе по Хаскелю, Чуть более опытный программист на Хаскеле предложит потоковые процессоры и инверсию управления, при этом построение простого варианта Easy Language займёт у него месяц, максимум.

То есть, программисту на Хаскеле есть, что предложить биржевикам.

И для понимания программы на Хаскеле не потребуется никакого парного программирования.

Имхо, степень программерского оптимизма в этом ответе не просто зашкаливает, она побивает все мыслимые пределы!

Как бы это лучше проиллюстрировать. Ну вот представьте себе, что есть уважаемый человек, который успешно в одиночку строит вот такие мосты (которые строятся лет десять-двадцать, а стоят потом по 300-500):

И вот смотрит он на мост “Золотые Ворота” из Сан-Франциско и говорит, что мол по большей части все это чисто технические вопросы и много чего из этого он бы сделал, да только железа такого обычному человеку взять негде. И вообще, мол, нам, камнеукладчикам, есть что предложить строителям “Золотых Ворот”.

Ну а чтобы эту аналогию прочувствовать получше, вот те самые “Золотые Ворота”:

Ну как, прочувствовали разницу? Думаю, что различия между разработкой моделей процессоров на Haskell-е и рил-таймовой трейдинговой биржевой платформой (как на техническом уровне, так и на организационном) будут не меньше. Поэтому-то и разбор по пунктам новости о возможностях новой системы от Fujitsu с оценками вида “Техническое дело, опять” выглядит даже не смешно, а печально – ведь наш программерский оптимизм и вера в то, что мы все знаем и можем – неистребимы. К сожалению.

PS. В заметке была использована фотография “Чертов мост”  с сайта http://club.foto.ru, автор Галина А.

PPS. Я сам к парному программированию отношусь неоднозначно. Но это уже совсем другая тема :)

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

Dmitry Vyukov комментирует...

> реальная оценка времени на разработку получается, если названный программистом срок умножить на три

У меня есть гипотеза (доказательств пока нет), что это - либо Pi, либо e.
Возможно тут работает какой-то фундаметальный неоткрытый принцип природы.

Dmitry Vyukov комментирует...

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

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

По-моему, у Роберта Гласса в его "50 заблуждениях" указывалось, что проблема не столько в том, что программисты дают неточные оценки. А в том, что эти оценки впоследствии не пересмативаются по ходу разработки.

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

Программист на Хаскеле знакомится с ленивыми списками на третьем примере в любом курсе по Хаскелю, ... построение простого варианта Easy Language ...

То есть, программисту на Хаскеле есть, что предложить биржевикам.

Или, в обратном и сжатом порядке:
Биржевикам предлагаются
Easy Language
Ленивые списки
(ну и наверняка балансировка красно-черных деревьев)

Я потому только слежу за ФПшниками(не вмешиваясь), и повторюсь, - они неадекватны.

Их предложения-рассуждения напоминают:
Бухгалтерам предлагается:
Простой язык макросов
База хранящая двойные проводки
И быстро обрабатывающая остатки по счетам

Глубже уровень неадекватности встречал только у сисадминов:
Поставьте Linux и он решит Ваши проблемы!
Офисная тетка вполне сможет ходить по инету и из него и набирать документы!
(то что большинству теток платят зарплату НЕ за это - им в голову даже во сне не приходит)

Попытаюсь охарактеризовать - это уровень "глубокого" инструментальщика который настолько погряз в процессе, что напрочь забыл конечную цель - а зачем оно вообще нужно, программирование это?

То есть ФПшники - это Каменщики (см Профессия - каменщик на RSDN). С Большой такой буквы. МЕГАкодеры! А так уже не студенты - то хронические.
Именно в рассуждениях о конечных программных продуктах и решениях, будь-то Eclipse, биржевая программа, "опердени" с "складами" - отчетливо это видно.
ИМХО, конечно :)

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

>>реальная оценка времени на разработку получается, если названный программистом срок умножить на три
Dmitry Vyukov> У меня есть гипотеза (доказательств пока нет), что это - либо Pi, либо e.
Возможно тут работает какой-то фундаметальный неоткрытый принцип природы.

я люблю менеджерам рисовать круг и диаметр :) И пояснять что если бы знали куда идем то путь был бы X, а в реале больше кругами, кругами вот и pi*X вырисовывается :D

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

>я люблю менеджерам рисовать круг и диаметр :) И пояснять что если бы знали куда идем то путь был бы X, а в реале больше кругами, кругами вот и pi*X вырисовывается :D

Вот это классно!

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

Да, умножать реальные сроки разработки надо на пи. Вот еще одно доказательство:
http://www.paloinsider.com/jedox/the-importance-of-pi-when-doing-bi-projects/

Dmitry Vyukov комментирует...

> я люблю менеджерам рисовать круг и диаметр :) И пояснять что если бы знали куда идем то путь был бы X, а в реале больше кругами, кругами вот и pi*X вырисовывается :D

LROTF
Надо будет попробовать

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

2Skynin:

>Я потому только слежу за ФПшниками(не вмешиваясь), и повторюсь, - они неадекватны.

Первоначально я хотел ответить, что по-моему, функциональщики всего лишь страдают синдромом "Когда в руках молоток, то все вокруг выглядит как гвозди". Но пообщавшись с thesz на эту тему дальше прихожу к выводу, что вы, вероятно, правы. Если и не все функциональщики, то один точно :(

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

Как раз упоминаемый тут Влад Балин (gaperton) хорошо объяснил почему нужно умножать:

Тем, что разработка — empiric process, а не defined process. В случае empiric process точность соблюдения технологии и процесса не гарантирует результата в принципе, потому, что какие бы "типовые" работы не были. Потому, что все они сопряжены с решением проблем, способ решения которых повлияет на структуру результата, и результат определяется не соблюдением технологии, а человеческим вкладом и личными качествами исполнителей.

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

Кстати в финансах функциональщина вполне успешно используется, второй после Эриксона пример промышленной разработки на ФП это Jane Street http://www.janestreet.com/technology/ocaml.php.

Правда они наверно не читали thesz'а и с дуру написали несколько миллионов строк на OCaml.

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

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

Skynin про неадекватов это у тебя от зависти :)

Я вот тоже завидую, так и не смог в функциональщики выбиться, последняя попытка закончилась прототипом на OCaml, если это перейдет в продукт (скорее продуктик) будет переписанно на C++ или python + C++. Библиотек (в основном GUI) нужных просто нет :(

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

>Правда они наверно не читали thesz'а и с дуру написали несколько миллионов строк на OCaml.

+1000 :)

>выгодно только за счет того что получается приток хороших увлеченных своей работой специалистов.

Да, думаю данный фактор так же присутствует.