Библиотека сайта

Карта сайта

Главная страница сайта

Региональные подразделения РФО

Подразделения РФО по направлениям исследований

 

Начало книги. Введение. Содержание.

Часть I. 

Владимир ШКУНДЕНКОВ Черное озеро

(Зарисовки из студенческой жизни конца 1950-х годов)

Часть I. 

Владимир ШКУНДЕНКОВ

Зачем физики строят ускорители? Антропокосмическая модель Вселенной

Часть II.  Владимир АРШИНОВ

На пути к коммуника-тивной Вселенной солидарности и альтруизма

Часть III.  Николас КУЛЬБЕРГ

ЦЕРН  и  институты  России

Приложение:

Джон Маклиш ФЕРГЮСОН

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

 

 

 

 

Копировать книгу целиком

 

Часть  IV.

 

Джеймс ПУРВИС (James PURVIS)

 

(Европейская организация ядерных исследований –

ЦЕРН, Женева, Швейцария.

Программист, руководитель группы в департаменте кадров)

К вопросу о простоте и элегантности информационных решений

Простота с исторической перспективы

Простота в разработке программного обеспечения

Опыт создания административных  информационных систем ЦЕРН

 

Простота с исторической перспективы

 

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

 

Еще в 400 году до н. э. Платон заметил:

 

«Красота стиля, гармонии, грации и хорошего ритма зависят от простоты».

 

Доводы в пользу важности простоты приводятся и учеными, и философами. Например, Эдвард Теллер (рожденный в Венгрии американский физик-ядерщик, р. 1908) говорил:

 

«Главной целью науки является простота, и по мере роста наших знаний все будет становиться проще».

 

Эту же мысль о науке и простоте продолжает Эйнштейн, говоря:

 

«Все должно быть изложено как можно более просто, но не проще того».

 

Способность разработки и создания простых решений не менее важна, чем способность схватывания, наблюдения и объяснения явлений в самых простых и фундаментальных терминах. И здесь люди самых разных талантов имеют одинаковые побуждения. По поводу музыки Фредерик Шопен сказал:

 

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

 

А художник и архитектор Леонардо да Винчи заметил, что

 

«Простота – это конечная стадия изощренности».

 

Простота  в  разработке  программного обеспечения

 

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

 

Сложности разрастаются, несмотря на наши постоянные стремления к простоте. Попытки предусмотреть в техническом задании все мелочи нередко приводят к тому, что 80% усилий затрачиваются на разработку 20% выполняемых функций.

 

Нам представляется, что путь к упрощению лежит через осознание систем и выделения в них составляющих частей. Наблюдая за природой, итальянский философ XIII века Томас Акинас написал:

 

«Если достаточно одного, чтобы сделать нечто, не нужно привлекать к делу нескольких. Ибо и природа не использует двух инструментов, где можно обойтись одним».

             

В XIV столетии английский логик Вильям Оккам сформулировал принцип «бритвы Оккама», заключающийся в исключении из объяснения всех предположений, не влияющих на рассматриваемую гипотезу или теорию. В наше время этот принцип более известен под названием принцип KISS (Keep It Simple, Stupid – «Не усложняй, болван!»), сводящийся к тому, что инженерные решения должны быть как можно более прямолинейными. Иллюстрацией применения этого принципа может служить история о том, как Томас Эдисон попросил молодого инженера определить объем сосуда очень сложной формы. Через несколько часов  инженер торжествующе закончил свои вычисления. Эдисон же просто заполнил сосуд водой до краев, а затем слил воду в контейнер с делениями. Помимо всего прочего оказалось, что детальные расчеты инженера дали неправильный результат. Принцип KISS часто используется при разработке программного обеспечения и архитектуры систем.

 

Несмотря на существование принципов, подобных KISS, и знаний об их применении в разработке программного обеспечения, проекты по-прежнему выполняются с задержками и перерасходом. Такое впечатление, что в основе проблем лежит усложнение систем, а попытки предусмотреть в техническом задании все мелочи могут привести к соотношению Парето, когда 80% усилий затрачиваются на разработку 20% выполняемых функций.

 

Многочисленные методологии и принципы были созданы для разрешения фундаментального противоречия: наших усилий по созданию простых решений и врожденной тяги к ним, с одной стороны, и естественной тенденции к усложнению – с другой. Эти принципы сегодня преимущественно представлены спектром методик быстрой разработки программного обеспечения (agile programming), таких как Скрам (Scrum), экстремальное программирование (Extreme Programming), функционально-ориентированная разработка (Feature Driven Development) и разработка программного обеспечения с учетом внесения изменений в будущем (Adaptive Software Development). Общим элементом этих методик является принцип построения лишь минимального ядра, из которого должны быть исключены все ненужные функции. Как пишет автор книги об английском языке «Элементы стиля» Вильям Странк:

 

«В предложении не должно быть ненужных слов, а в параграфе не должно быть ненужных предложений, точно так же, как в чертеже не должно быть лишних линий, а в машине не должно быть лишних деталей».

 

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

 

Опыт  создания  административных  информационных систем  в  ЦЕРН

 

В 1994 году проект ЦЕРН по разработке административных информационных систем начал сотрудничество с командой русских инженеров из ОИЯИ, Дубна (руководитель группы – Владимир Шкунденков). Это сотрудничество породило новую волну мышления в нашей команде. Одним из самых поразительных впечатлений стала способность русских коллег решать имеющиеся проблемы технологиями «меньшей степени сложности». Вместо того, чтобы набрасываться технологией на проблему, русские обладали способностью рассмотреть проблему под другим углом зрения. Как мы видели в случае с измерением Эдисоном объема сложного сосуда, сложные проблемы могут порождать сложные решения, но если правильно сделать первый шаг, то эти же проблемы могут иметь и простое решение. Подобный подход продемонстрировал Владимир при разработке скоростного светового карандаша, когда имеющаяся сложная проблема также была разрешена сравнительно простыми технологиями.

 

Проблемы медленной работы программного обеспечения сегодня зачастую решаются покупкой более производительной техники. Такой путь, безусловно, предпочитают на Западе (двигая тем самым экономику «Микрософта»!), ввиду его кажущейся «большей простоты» по сравнению с альтернативным вариантом улучшения эффективности и качества архитектуры самого программмного продукта. Часто мы полагаемся на «легкое» решение: позволить машине думать и решать проблемы технологиями, а не человеком.

 

Решать проблемы увеличением компьютерных мощностей всегда проще, чем находить нестандартные инновационные решения, особенно когда инновация требует поиска «лучших», то есть «элегантных», но в то же время «простых» решений. Найти сложное решение для сложной проблемы нетрудно. Гораздо больше сил требуется на простое и элегантное решение сложных проблем. Однако по иронии природы человеческий мозг обладает врожденной склонностью к выявлению «красивых» решений. Подобно тому, как при посещении картинной галереи мозг сортирует экспонаты, отбрасывая часть из них и концентрируясь на красивых картинах, при поиске решений мозг останавливается и обдумывает самые «привлекательные» из вариантов. В информационных технологиях красота обычно кроется в простоте. В отличие от чисто «технологического» подхода решения сложных проблем сложными методами (использовавшегося в ЦЕРН в 1992–1994 годах), сочетание «красоты», «простоты» и «технологий» (то, что Владимир называет b-technologies) позволяет решать проблемы большой сложности простыми, но мощными решениями.

 

 

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

 

Сотрудничество с ОИЯИ фактически заставило нас переосмыслить процесс разработки программного обеспечения. Отчасти это было вызвано тем, что знания участников команды лежали в разных областях. Я и Матс Моллер (руководитель проекта BHT) обладали знанием предметной области, то есть разбирались в меняющихся требованиях ЦЕРН. Наши русские коллеги имели опыт программирования и работы с программными средствами. Опробовав несколько вариантов организации работы, мы сочли наиболее эффективным подход, при котором я и Матс разрабатывали «скелет» приложения, включавший в себя примеры отчетов, запросы к базам данных и т.п., в то время как русская команда фокусировалась на разработке. В некоторых областях, таких как разработка пользовательского интерфейса, мы работали вместе, получая при этом весьма значительные результаты при простых принципах разработки.

 

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

 

Похожая ситуация сложилась и с системой электронного документооборота ЦЕРН (EDH). Еще в 1993 году руководитель проекта Юрген де Йонге определил слабости первоначальной архитектуры EDH. Они были похожи на слабости BHT: высокая стоимость технического обслуживания и высокая стоимость модификаций. В частности, любые изменения бизнес-логики требовали повторной инсталляции EDH; кроме того, EDH, как и BHT, требовала для работы мощной машины. Вследствие этих причин стоимость адаптации системы к меняющейся среде была чрезмерно высока.

 

Версия 2.1 системы EDH стала отчасти удачной попыткой решения многих из существующих проблем. Применение «тонкого клиента» означало, что новые документы EDH, новые маршруты и новые правила теперь можно было добавлять в систему, не меняя программного обеспечения на клиентских компьютерах. Для своего времени это решение было революционным. Тем не менее система EDH страдала от такой же, если не более серьезной, фундаментальной проблемы со значительным расходом ресурсов на техническое обслуживание, что и ранние версии BHT. Как и в случае с BHT, внимание программистов концентрировалось на конечном продукте, а не на самом процессе разработки, вследствие чего внутренняя структура EDH превратилась в джунгли из разнообразия технических приемов и технологий, применяемых и отстаиваемых разработчиками этой постоянно меняющейся команды.

 

В 1998 году мы реорганизовали команды BHT и EDH, внеся в команду EDH, до этого состоящую исключительно из сотрудников ЦЕРН, идеи из команды BHT (ЦЕРН–ОИЯИ).

 

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

 

В начале 1999 года мы применили новый подход для создания первого электронного документа EDH (это была заявка на покупку оборудования со склада) и были готовы приступить          к созданию еще 10 или 20 документов.

 

Срок разработки документов с использованием архитектуры предыдущей версии EDH составлял около 10 месяцев. Новый подход уменьшил срок разработки до двух месяцев. Оригинальный шаг, предпринятый Ростиславом Титовым, работающим в команде EDH, позволил увеличить производительность еще вдвое. Ростислав внедрил в EDH блок, называемый сейчас «суперклассами» и родственный идеям, лежащим в основе принципов построения скоростного светового карандаша. Этот блок разительно уменьшил «маргинальную стоимость» новых разработок в EDH. Конечным результатом стало повышение продуктивности более чем в десять раз по сравнению с оригинальной архитектурой и реализацией EDH.

 

Успех системы EDH в ЦЕРН оказался огромным, и сейчас она используется более чем 10 000 пользователями.

 

Наиболее свежий пример применения рассматриваемого подхода датируется 2005 годом. Границы этой разработки впервые вышли за пределы ЦЕРН, поскольку разработка велась в сотрудничестве с внешними компаниями. Примерно в 2002 году возникла идея расширить складской каталог ЦЕРН (насчитывающий около       20 000 наименований) до размеров «виртуального веб-каталога», позволяющего покупать изделия от различных поставщиков. Суть была в том, чтобы при помощи «виртуального склада» избавиться от затрат на содержание настоящего склада тех же размеров. После двух лет работы нам наконец удалось добавить   в каталог 40 000 дополнительных наименований продукции от одного из поставщиков. Однако вскоре стало ясно, что хотя задача и была решена успешно, но найденное решение нельзя масштабировать. Поэтому в 2005 году проблема была рассмотрена с другой точки зрения и при помощи одного русского инженера был разработан новый подход. Всего через несколько месяцев у нас появился виртуальный каталог более чем с 500 000 наименованиями продукции от многих поставщиков, причем число поставщиков и изделий продолжает расти.

 

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

 

Новый подход имеет и другое ключевое преимущество, особенно важное для постоянной меняющейся среды ЦЕРН, а именно большую гибкость получающихся программных продуктов. Жизненно важно, чтобы программный код мог быть быстро приспособлен к постоянно меняющейся среде. Точно так же, как пилоту самолета требуется все время корректировать курс при полете в шторм, в ЦЕРН необходимо постоянно изменять и подправлять программное обеспечение для удовлетворения меняющихся потребностей организации. Мы видели, что в ранних версиях EDH и BHT затраты на такое «адаптивное техническое обслуживание» при изменении нужд организации оказывались иногда выше стоимости полной переделки программ. Однако последняя версия EDH не только была разработана с меньшими затратами, но и может быть с небольшими затратами приспосабливаться к меняющейся среде.

 

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

 

Поиск простых, элегантных и рентабельных решений особенно важен в связи с быстрыми темпами роста сложности современных информационных систем, и мы видим, что сейчас внимание начинает сосредотачиваться на этих вопросах. Компания SAP выпустила руководство по разработке программ «простыми принципами». Журнал DM опубликовал статью под названием «Принятие простоты может принести большие плоды в коммерческой деятельности»Embracing Simplicity Can Reap Huge Business Intelligence Benefits»). Эдуард Де Боно опубликовал книгу      о том, как достичь простоты в проектировании. Лаборатория средств аудиовизуальной информации Массачусетского технологического института начала экспериментальную исследовательскую программу, ориентированную на поиск технологий разработки, которые были бы более понятны, более просты для использования и, в конечном итоге, более приятны для работы. Эта программа называется «Простота» (Simplicity).

 

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

 

            «Просто – это необходимое условие надежности»

- Эдсгер Дейкстра (ученый с мировым  

именем в области компьютерных наук).

 

«Мой старый учитель любил говорить: “Думай проще”, - имея в виду, что нужно разбивать целое на простейшие части, возвращаясь к основным принципам»

- Фрэнк Ллойд Райт (один из наиболее  

             влиятельных американских архитекторов).

 

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

- Давид Гелернтер, профессор в области компьютерных наук Йельского университета.

 

            «Нет величия там, где нет простоты, добра и правды»

                                        - Лев Николаевич Толстой.

 

 

                                                          15 сентября 2006 года (Женева)

 

 

Джеймс ПУРВИС

(James PURVIS)

 

Англия, Испания, Америка и Россия

(Рассказ о моей жизни)

 

Я родился в августе 1968 года в Слау (Slough) под Лондоном, одном из самых богатых в культурном и этническом отношении городов Великобритании. Моя мать сделала успешную карьеру в банковском деле, став управляющим экспортными операциями (была фактически первой женщиной, подписывавшей документы крупного банка). Отец был начальником производства в фирме электроники, впоследствии открыл свой бизнес в области транспортных услуг – перевозок пассажиров из аэропорта Хитроу.  

 

      В 1970-х годах клиентами моего отца нередко были руководители высшего звена и кинозвезды. Часто эти важные персоны предпочитали ехать в Лондон, садясь, не, как это традиционно было принято, на заднее сиденье машины, а на переднее, чтобы   в дороге можно было поговорить с водителем Джимом – весьма общительным человеком. И вот один из таких разговоров – с американским управляющим в области нефтедобычи – окончился тем, что отцу предложили, начиная с 1975 года, работу в нефтяном бизнесе в Сахаре. Так как вблизи нефтяных месторождений не было никаких школ и бытовой инфраструктуры, компании решили отправить семьи в Испанию, преимущественно в Пальма-де-Майорка.    

 

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

 

      Тем временем в Испании и на Майорке происходили существенные изменения. Диктатор Франко умер, и Испания начала переход к демократии. Среди моих детских воспоминаний остались ощущения скорбящей страны и того, что жизнь в течение этого переходного периода действительно несколько ухудшалась. Я помню, как во времена Франко однажды прочитал о юноше, которого застрелили гвардейцы только за то, что он писал на стенах. После Франко в газетах сообщалось о гораздо большем количестве преступлений и уж конечно на стенах появилось гораздо больше надписей. Прежде на пляжах царила строгая дисциплина и строгие нравы по части одежды. После 1975 года все это исчезло, авиалинии стали доставлять все возраставшее число отдыхающих, и стала развиваться новая, туристическая индустрия.

 

      Все больше людей стало путешествовать, то же делал и я.       В 1980 году моему отцу предложили позицию менеджера в небольшой нефтяной компании, располагавшейся в Денвере (США) и занимавшейся разработкой скважин в Оклахоме. Мы отправились в Соединенные Штаты, где прожили год. Этот год оказал огромное воздействие на мою жизнь, я многому научился. В противоположность прежнему классу из пяти–десяти человек в школе, где я теперь учился,  каждый класс имел до пяти уровней! По математике я был помещен в самый высокий уровень (изучение дифференциального исчисления в 11 лет) и уже стал заниматься компьютерным программированием на универсальной ЭВМ в школе и на TSR-80 – дома.

 

      США, казалось, были на расстоянии нескольких световых лет впереди Европы по развитию технологий. В каждом магазине имелись устройства для считывания штрихкода и электронные кассовые комплексы. В Европе такие технологии появились лишь спустя 5 лет. Я уже программировал механизмы произвольного доступа к файлам на DOS для Apple II+ в 1981 году, тогда как в Великобритании Клив Синклер только начинал выпуск известных машин ZX80 и ZX81.

 

      Однако равновесие между работой и отдыхом в США с точки зрения ребенка воспринималось совсем по-другому. Когда мой отец работал в нефтяном бизнесе в Европе, я видел его примерно 6 месяцев в году. В США он уезжал на работу в 6 утра, возвращался в 8 вечера, часто работал в выходные и имел очень короткий отпуск. Несмотря на то, что в Америке имелись все условия получить хорошее образование, практический опыт, сделать карьеру, заработать деньги и т.д., мы были вынуждены возвратиться в Европу для восстановления гармонии в семейной жизни. Мой отец ушел из сферы менеджмента и возвратился к работе на нефтяных платформах в качестве инженера-электрика.

 

      Итак, мое детство и отрочество прошли на Майорке. Я получил там школьное образование, которое никогда не забуду. Готовясь к вступительным экзаменам в университет, я изучал английскую литературу (от «Гамлета» У. Шекспира до «Бесплодной земли» Т. Элиота), историю (XVII столетие в истории Англии, «межвоенный» период 1919–1939 годов), математику (собственные векторы, собственные значения и тому подобное),  а также физику.

 

      Возвратившись на Майорку из США, я с самого начала увлекся компьютерами. Я был, возможно, единственным, кто не имел летнего загара, поскольку проводил часы и дни, программируя Apple II+. Я продал сразу несколько программ журналу Nibble (это название переводится как «Полбайта»), которые завоевали популярность, а в 14 лет создал игру по созданию трехмерных лабиринтов, которая успешно продавалась, а я получал свои авторские гонорары.

 

      Что касается занятий спортом, то еще подростком я начал заниматься виндсерфингом и постепенно стал уделять ему по несколько часов в день, отнимая это время от занятий компьютерами, и так каждый день в течение лета. Детские годы, проведенные на Майорке, много дали мне в социальном плане,    я научился легко сходиться с людьми!

 

      В 1985 году я уехал в Великобританию и поступил в Брунельский университет (Brunel University), где учился в течение 1986–1990 годов. Я тогда еще не знал точно, какого рода работа будет меня привлекать, так что этот университет с его учебным планом, где 6 месяцев учебы чередовались с 6 месяцами практической работы, был идеальным местом для меня, чтобы я мог понять, какая именно работа мне интересна и нужна. Я изучал информатику (особенно математику для проектирования языков программирования, компиляторов и операционных систем, специализировался в математических спецификациях (Z, Lotos…). В течение учебы я работал два раза по полгода в главном офисе компании Бутс (Boots) и один раз полгода работал в ЦЕРНе.

 

      Во время моего пребывания в Boots произошла интересная история, пример того, как простая ошибка может привести к опустошительным разрушениям. Я разрабатывал программы на языке управления заданиями JCL и допустил неточность в процедуре обработки ошибок одной из программ пополнения запасов продукции. Когда программа была запущена в эксплуатацию, она не смогла найти информацию по запасам зубной пасты. Программа должна была прерваться. Однако вместо того, чтобы прерваться, программа предположила, что никакой зубной пасты не осталось, поэтому она начала автоматически заказывать огромное количество зубной пасты для более чем 400 магазинов на Юге Англии. Такое «чрезмерное заказывание» в свою очередь вызвало необходимость увеличить производство. Поскольку был выходной день, эта проблема повторилась дважды! Помню, как я пришел на работу, где вовсю звонили телефоны и нам сообщали, что к магазинам подъезжают грузовики с зубной пастой, тогда как она была абсолютно не нужна. Большой урок, извлеченный из маленькой ошибки …

 

      Когда я учился на последнем курсе, мне как-то позвонил мой дядя, который управлял фабрикой, производившей одежду для Marks & Spencer и других крупных компаний розничной торговли в Великобритании. Фабрика очень успешно работала во времена правительства Тэтчер, и ее посещала непосредственно сама Маргарет Тэтчер. Однако теперь, когда Азия становилась сильным конкурентом, для фабрики наступали трудные времена. Мой дядя звонил мне, чтобы узнать, мог бы я со своими компьютерными навыками помочь установить систему, способную анализировать причины неполадок в бизнесе. Именно в этот момент я осознал, что не могу помочь. Все мои навыки программирования были бесполезны, если они не подкреплялись дополнительными знаниями в области финансов или бизнеса. Я не смог помочь ничем. Вскоре фабрика моего дяди обанкротилась, и он, его жена и дети потеряли работу, дома, автомобили, деньги – словом, все.

 

      Я решил бросить программирование. Я рассылал резюме        и ходил на собеседования по поводу работы, не связанной с компьютерами. Я чувствовал, что должен учиться бизнесу. Я решил заниматься стратегическим консалтингом и подал заявление        о приеме на работу в компанию «Bain, Boston Consulting & McKinsey». Однако во время рассылки своих резюме я получил предложение от Джона Фергюсона работать в проекте по разработке перспективных систем административной поддержки (AIS – Advanced Informatics Support project) в ЦЕРН в роли стипендиата (я оказался первым стипендиатом, работающим в администрации ЦЕРН). Я ухватился за это предложение, новый поворот в жизни и возможность реализации мечты захватывали меня, это был другой способ приобрести опыт, в котором я так отчаянно нуждался.

 

      Проект AIS и его успехи описаны во многих местах. Моя поездка имела для меня обучающий характер. Моя начальная цель в 1990 году состояла в том, чтобы просто «быть полезным», то есть приобрести дополнительные практические навыки, которые вместе с компьютерными навыками могли бы оказаться ценными в бизнесе. Благодаря сотрудничеству с Объединенным институтом ядерных исследований (Дубна) я узнал даже больше.

      В 1989 году у меня была полугодовая практика в ЦЕРН. Мое первоначальное задание, которое дал руководитель Райнуд Мартенс (Reinoud Martens), заключалось в  написании системы управления исходным кодом. Я выбрал средство для создания интерфейса конечного пользователя, написал документацию и разработал программное обеспечение, запущенное в эксплуатацию через шесть недель после начала работы. После решения этой задачи я вместе с внешним консультантом работал над переносом всего содержимого большой ЭВМ фирмы IBM на новую архитектуру, построенную на базе универсальных ЭВМ.

 

      После возвращения в ЦЕРН в 1990 году я сначала работал в области системного программирования и написал систему управления магнитными лентами, указывавшую, какие магнитные ленты необходимо установить в компьютерном центре (это были времена, когда люди, а не роботы занимались монтированием магнитных лент). После этого я перешел в проект AIS в команду, занимавшуюся разработкой программных инструментов для конечных пользователей, которая в конечном счете разработала системы EDH & BHT (систему электронного документооборота ЦЕРН и программу «Инструментальный комплекс распорядителей бюджетов») в 1992 году.

 

      В 1995 году я был приглашен Владимиром Шкунденковым посетить Дубну, расположенную в 100 километрах на север от Москвы, в рамках сотрудничества с Объединенным институтом ядерных исследований (ОИЯИ) по проекту AIS. Это было, мне кажется, поворотным моментом в моем понимании методов программных разработок.

 

      Я приехал в Дубну в воскресенье. На мне был рабочий костюм, я был готов к работе – ведь, в конце концов, когда русские были в Женеве, они работали семь дней в неделю, так что я ожидал увидеть то же самое и в России. Однако я был захвачен врасплох. Мне оказали радушный прием и пригласили отведать водки. Затем мне сказали, что мы будем играть в футбол. У меня не было никакой спортивной обуви, шорт, ничего в этом роде, только одежда для работы. Русские предоставили мне все – и все в лучшем виде! После дружественной игры (это был единственный общий язык, который мы понимали) мне предложили поплавать в Волге. Река была такого же оранжевого цвета, как Айрон Брю (известный шотландский напиток). Но мое впечатление осталось самым приятным, потому что я сумел не напиться этой воды, так же как я никогда не пил Айрон Брю.

 

      Я очень мало знал о России, всё для меня было новым. Хотя   я воспитывался и вырос за границей и немного путешествовал,    я никогда не встречался с подобной культурой. Работало слишком много людей, в магазинах всегда требовалось как минимум несколько сотрудников (один встречал посетителей, другой шел за товаром, третий стоял за кассой), и еще я вспоминаю картины, когда люди косами косили траву на полях. Однако я думаю, что люди, которых я встречал, были столь же очарованы Европой, как я был очарован ими. Проходя мимо людей на улице редко можно было увидеть улыбки или почувствовать теплоту, но после приглашения в дом вас встречают и обращаются с вами просто по-царски. Не забуду, как однажды меня пригласили в гости и засыпали вопросами типа «Американцы действительно верят в волшебство Дэвида Копперфилда

 

      Мы с Владимиром посетили много храмов и городов, и все они произвели на меня сильное впечатление. Но самое большое впечатление – это достижения. Нация, люди, культура достигли огромных результатов при помощи незначительных ресурсов. Им не требовались мощные компьютеры, последние технологии – у них было что-что еще. Владимир продемонстрировал подход к созданию скоростного светового карандаша, гораздо более эффективный, чем западные аналоги. В чем заключался секрет их метода? Это была не технология, не методология, это была философия. Было непросто научиться, понять и применять эту философию, как невозможно, просто прочитав «рецепт», применить его. Я начал понимать это, когда Владимир водил меня по художественным галереям, по храмам, после чего мы обсуждали конструкции танков времен Второй мировой войны, а также проблемы, связанные с протяженностью, многообразием и в то же время единством Российской империи. Философия вращалась вокруг идеи «красоты». Похоже было, что на Западе мы искали свой рецепт «резьбы по камню», но выбрали неправильный путь. Как когда-то сказал Микеланджело, каждый каменный блок камня хранит в себе статую, и задача скульптора и заключается в том, чтобы ее обнаружить. Для Микеланджело это было просто – вы только надрезаете верхний слой и затем останавливаетесь, но как научить этому того, кто не обладает подобным восприятием?

      Для Владимира и многих русских их философия была проста. Суть ее заключалась в красоте, но возможно ли применить эту философию к Западу?

      Я полагаю, что именно после возвращения из России у нас стало появляться какое-то представление о возможности соединить эту русскую философию с нашим западным логическим математическим подходом. Уже с первым экспериментом при разработке BHT (Budget Holders Toolkit – системы контроля финансов) мы получили очень впечатляющие результаты на основе простых принципов дизайна (и к тому же в рекордные сроки).

      Еще не осознавая этого, мы фактически стали использовать тот метод рассуждения и практической работы, который привел к существенному росту производительности во всем процессе разработки программного обеспечения. Выпуск версии 4 BHT (1995) был осуществлен в рамках этого сотрудничества в очень короткий срок. Владимир заметил некоторое изменение в методах рассуждения у членов рабочей группы, но интересно было то, что сами члены группы, возможно, менее всего осознавали произошедшие изменения в их образе мышления.

      Разработка первой версии BHT заняла почти два года, а вот последнюю версию (по русскому подходу) создали  всего за несколько месяцев. Если мы однажды достигли такого порядка роста, неужели мы не могли бы достигнуть этого снова? Я полагал, что могли. После того как мы стали уделять больше внимания «процессу», чем «продукту», стали возникать идеи создания универсального инструмента для создания административной отчетности (MRT – Management Reporting Toolkit). Основным движущим принципом для создания MRT была идея о том, что, если вы имеете систему создания административной отчетности типа BHT, позволяющую создавать, скажем, отчеты n типов, то создание отчета n + 1 типа не должно требовать дополнительного программирования, достаточно лишь определить структуру этого отчета на каком-то «языке высокого уровня».

      Мы попытались применить принцип дизайна MRT при создании первой версии BHT для Web.  Это повлекло за собой разделение программирования и знаний по следующей схеме:

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

      - что лучше всего сделает программист (управление исполнением отчетов, выборкой результатов и т.д.);

      - чего требует конечный пользователь.

 

     Как и в подходе с созданием Владимиром скоростного светового карандаша, MRT стремится разграничить область проблемы и область решения. В основе обоих подходов лежат очень похожие мысли и одинаковая философия. Предельная стоимость разработки нового отчета в MRT чрезвычайно мала, благодаря чему затраты на разработку и обслуживание оказываются более чем в 10 раз ниже, чем в первой версии BHT. Примененные в BHT принципы MRT затем были адаптированы в архитектуру MRT-light, ставшую основой для многих программных приложений. Впоследствии эти же принципы стали неотъемлемой частью технических требований на разработанную в ЦЕРН «современную программную архитектуру для создания административной отчетности» (ART – Advanced Reporting Toolkit). Эта архитектура получила широкое распространение в различных веб-приложениях ЦЕРН для создания деловых отчетов и все еще используется и расширяется и сегодня, в 2007 году.

 

      В октябре 1998 года команды разработчиков BHT и EDH были реорганизованы, что позволило распространить идеи из совместной команды ЦЕРН/ОИЯИ, занимавшейся созданием BHT, на проект электронного документооборота ЦЕРН EDH, представленный до этого преимущественно сотрудниками ЦЕРН.

 

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

 

      В начале 1999 у нас появился первый документ EDH, созданный на основе этого подхода (это была заявка на заказ оборудования со склада), и мы собирались создать еще 10–20 типов электронных документов.

 

     Я полагаю, что суть философии, о которой мы узнали в 1995 году, заключается в использовании простых методов, но без чрезмерного упрощения. Альберт Эйнштейн однажды сказал: «Все должно быть сделано так просто, как только возможно, но не проще этого». Леонардо да  Винчи говорил: «Простота – это предел совершенства».

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