Об оценке профессионалами

На международных конференциях поданный материал оценивается несколькими экспертами. Каждый из них выставляет оценки по предложенным организаторами критериям и определяет оценку в целом

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

На одной из конференций при рецензировании нашего доклада сложилась такая ситуация: из двух экспертов один, считающий себя профессионалом, оценил нашу работу весьма "кисло", а второй (присвоивший себе более низкий уровень компетентности в этой области) выставил почти по всем критериям высшие оценки. Работу приняли, но не это главное. Мои соавторы, студенты-программисты, обрадовались конечному результату, но расстроились, узнав оценку эксперта, назвавшегося "крутым" профессионалом.
Появление таких оценок вполне естественно - ведь продвинутые программисты, как и математики, любят решать трудные задачи (простые им решать неинтересно). Трудные же задачи решают люди из относительно узкого круга, которые образуют элиту в рассматриваемой области. У них вырабатываются свои (очень высокие) критерии оценки работ, и достижения других в подавляющем большинстве являются для них "ботвой" (этот термин безобиден, так как в его основе лежит сельское хозяйство, а не героиновая культура, как у слова "прикольно", см. "КТ" #636).

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

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

При этом им абсолютно безразлично, что ситуация в программировании напоминает круг света от фонаря: чем шире круг, тем больше граница с темнотой.

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

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

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

О том, к чему это приводит, пишут в своей книге [Ослэндер Д.М., Риджли Д.Р., Ринггенберг Д.Д. Управляющие программы для механических систем. Объектно-ориентированное проектирование систем реального времени. - М.: Бином. Лаборатория знаний. 2004] сотрудники кафедры механотроники Калифорнийского университета в Беркли: для систем реального времени в 1997 году 80% всех проектов были вовремя не внедрены из-за плохого качества программного обеспечения (ПО).

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

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

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

Кстати, в автоматном программировании ("КТ" #633), которое было предложено значительно раньше, чем была написана книга специалистов из Беркли (2002 г.), я использую те же самые идеи, "кощунственные" для традиционного программирования.
Обобщая сказанное, хочу посоветовать талантливым программистам заниматься разработкой методов, технологий и инструментальных средств, а не решать за профессионалов прикладные задачи. Это позволит широкому кругу профессионалов в различных предметных областях использовать указанные разработки программистской элиты, что должно привести к синергетическому эффекту, выражающемуся в резком улучшении качества разрабатываемых программ.

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