[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. Я сам к парному программированию отношусь неоднозначно. Но это уже совсем другая тема :)