Alan Carter - The Programmers Stone (Программистский камень)

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

Мы знали, что не помогут сами по себе элементы лучшего опыта индустрии. Не помогут ни инвестиционные вливания, ни обучение. Не помогут инновационные программы Качества, которые явно включают такие целостные концепции как «Дзен и Искусство ухода за мотоциклом» Роберта Персига (Robert Pirsig's Zen and the Art of Motorcycle Maintenance ), которые в большей части индустрии считают слишком радикальными, чтобы с ними экспериментировать. Не помогут ни многолетняя практика, ни многие годы академического образования.

Мы посчитали, что имелся единственный способ продолжить исследования, если уж приверженная объективным метрикам индустрия не смогла найти этот X-фактор, — рассмотреть субъективный опыт работающих в области программной инженерии людей.

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

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

Цель этой работы — донести элементы «опыта» или «взглядов», на которые повсеместно ссылаются, но редко описывают. Многие темы — это то, что программисты обсуждают за пивом. Кажется странным, что никто не стремится узнать, как проблемы, которые программисты считают наиболее важными, соотносятся с «формальными» структурами современной инженерии. Здесь мы делаем именно это.

Если мы попали в точку, большинство программистов получает удобный случай поместить волновавшие их долгие годы проблемы в ясный рабочий контекст. Мы предлагаем расслабиться и хорошо провести время!

Программная инженерия находится в ужасно плачевном состоянии. Так называемый «кризис программного обеспечения» был осознан в 1968, но несмотря на тридцатилетние усилия и сотни опубликованных предположительно фундаментально новых концепций, общее состояние индустрии ужасающе. Проекты выходят за рамки бюджетов или превращаются в неразгребаемые кучи. Оценки — искусство черной магии. Многие проекты решают вчерашние проблемы пользователей, а не сегодняшние. Техническое качество большей части кода отвратительное, что вызывает проблемы сопровождения и высокие затраты на эксплуатацию. И в индустрии все еще есть отдельные программисты и группы, которым нравится модель водопада (staggering) и воспроизводимые успехи (repeatable successes). Хотя существует множество способов измерения продуктивности программистов, некоторые программисты оказываются в сотни раз более продуктивными, чем большинство, независимо от методов расчетов. Если бы вся индустрия работала также, как малая доля великолепных программистов, то экономика сразу бы это заметила. Если бы стало возможным писать сложные, надежные программы быстро и дешево, увеличился бы интеллектуальный потенциал общества и его благосостояние.

В рамках предлагаемой модели эту проблему можно понять. То, что представляется как социально обусловленное общепринятое мышление (называемое паковкой— packing), основано на действии. Чтобы быть хорошим каменщиком, паковщик должен знать, что делает каменщик. Но что же делает программист? Большинство разрабатываемых паковщиками моделей программирования являют собой концепцию Программной Фабрики. В ней пункты требований от заказчиков входят в одну дверь и обрабатываются рабочими по описанной в руководствах процедуре. Когда производственная линия завершает свою работу, программа выползает из другой двери. Это работает на автомобильных заводах.

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

Работники программной фирмы не похожи на работников в цехах автозавода. Сегодня работников в цехах можно заменить роботами, но по-прежнему нужны люди, использующие творческий подход к «настройке» фабрики. Программисты делают ту же работу, что и офис на заводских задворках, и мы не можем научиться этой работе, играя на полу цехов автозавода.

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

Чтобы понять, что же на самом деле делают программисты, требуется альтернативная стратегия мышления (называемая картостроение— mapping), поскольку программирование по сути — это процесс усвоения возможностей системы, природы задачи и желания, а затем выражение результатов исследования на языке программирования. Вся суть в исследовании деталей наших желаний и понимание их таким способом, что мы можем отследить всю их сложность. Решение проблемы картостроителем может привести к красивым, компактным, элегантным программам, в которых нет места для ошибок. Картостроение может осуществлять программирование, но способ, каким оно это делает, невозможно объяснить на языке паковщика (ориентированном на действия).

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

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