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

The Programmers' Stone

Глава 1. Мысли о мышлении

Истоки подхода

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

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

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

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

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

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

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

Картостроение и программная инженерия

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

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

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

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