Михаил Донской
Автор — известный российский системный программист, зав. лабораторией Института системного анализа РАН, разработчик шахматной программы «КАИССА» — первого чемпиона мира среди шахматных программ, Скончался 13 января 2009 года на 61-м году жизни.
У каждой профессии есть свой романтический период после которого она превращается в рутинную. Быть шофером в начале прошлого века было трудно и почетно. Сегодня автомобиль может водить любой желающий, а в большинстве районов США жизнь без автомобиля практически невозможна. Таким образом, профессия шофера за какие-то 100 лет прошла полный цикл — от интеллектуальной и романтической до бытовой и повседневной. Новые профессии имеют гораздо более короткий цикл. Особенно это верно по отношению к профессиям, связанным с информационными технологиями. Так получилось, что время моей жизни практически совпало с жизненным циклом моей профессии. Я – программист. Сами компьютеры появились в 1940-х годах, то есть в то же десятилетие, когда я родился. В этой статье я хочу, вспоминая свою профессиональную жизнь, напомнить, как менялась профессия программиста.
Когда я школьником учился программировать на ЭВМ М-20, в СССР программистами были известные математики, на ходу выдумывавшие то, чему сейчас учат в школе. В группе программистов Института теоретической и экспериментальной физики, где для вычислительных работ в исследованиях ядерной физики стояла та самая М-20, придумали массивы, списки, необходимость использования подпрограмм и многое другое. Один из моих учителей — Г.М. Адельсон-Вельский придумал хэш-память. Подробности можно найти в книге другого моего учителя – А.С. Кронрода «Беседы о программировании». Еще до Дийкстры основные принципы структурного программирования были изложены А.Л. Брудно в книге «Программирование в содержательных обозначениях». Там же, в Институте, была создана первая шахматная программа.
В то время программировали в кодах, память под программы и переменные распределяли своими руками, и известны случаи, когда на одно и то же место грузились разные подпрограммы, и всегда работала только последняя. Всерьез была распространена так называемая «польская игра», когда надо было уложить заданный алгоритм в минимальное число ячеек памяти. В итоге тогда шахматная программа ИТЭФ, предшественница «Каиссы», умещалась в памяти М-20 в 4096 ячейках, каждая из которых имела 48 разрядов (теперь это называют битами). Где-то рядом уже существовал Алгол-60, но им «настоящие» программисты не пользовались, поскольку техники отладки практически не было. Чуть позже большую популярность получила статья «Почему настоящие программисты не пишут на Фортране».
Мои студенческие годы пришлись на целый ряд советских вычислительных машин – Раздан-3 , Минск 1, 2, 22, 32, Урал-14, все они имели пульт, за которым сидели программисты, а программы и данные вводились с перфокарт или с перфолент. АЦПУ — устройство «широкой» печати — появилось только в конце 1960-х. Чтобы быстрее писать программы для этих машин мы сами разрабатывали операционные системы. Тут уже требовалась высокая техника программирования, поскольку эффективность операционной системы была необходима для самой возможности ее использования.
Рассказывают, что в операционной системе «Пульт», написанной в Вычислительном центре АН СССР для БЭСМ-6, был счетчик ошибок оператора, и при достижении некоторого порога система выдавал «вежливое» сообщение «А если ты – дурак, то не садись за “Пульт”». Когда директор ВЦ академик А. Дородницын инспектировал систему, он понажимал несколько раз случайные кнопки и был крайне огорчен полученным результатом.
О серьезности задач, которые тогда приходилось решать на тогдашних компьютерах, говорит то, что одним из моих проектов в студенческое время была система инверсного поиска патентов для экспертов. В МГУ отделение вычислительной математики было на мехмате, но я учился на отделении математики. Сдавая зачет по программированию, я должен был аппелировать к своему профессору М.Р. Шуре-Буре, поскольку его аспиранты, принимавшие зачет, программировать почему-то не умели. И вообще на мехмате программирование считалось чем-то вроде предательства чистой математики, и всерьез на моем курсе им занималось не больше десятка человек. Была даже частушка: «Меня милый не целует, не садится близко, говорит “я – математик, а ты – программистка”». А потом 90 процентов выпускников с моего курса пошло-таки работать программистами.
Мне посчастливилось заниматься в семинаре по эффективным алгоритмам, на котором моими сокурсниками было придумано несколько классических алгоритмов. М. Кронрод построил оптимальный алгоритм упорядочения, Е. Диниц и А. Карзанов создали целую серию алгоритмов по потокам в сетях. Карзанов потом стал автором классических работ по линейному программированию. Мой диплом представлял оптимальный алгоритм решения задачи о назначении и состоял из полутора страниц.
Конец моих студенческих времен совпал с революцией в компьютерах. Появились компьютеры «общего пользования» с системами разделения времени. Это IBM 360, ICL 4-70, ЕС ЭВМ. Писать в кодах для таких машин стало принципиально невозможно, и на передний план вышел (как наименьшее зло) язык ассемблера. Были и другие языки программирования — Фортран, Кобол, Алгол, PL-1, но они не позволяли эффективно контролировать оттранслированный код. Мой сосед по кабинету в Институте проблем управления — ИПУ М. Фурман, на мой изумленный вопрос, как ему удается программировать на PL-1, заметил, что он в уме транслирует все операторы, прежде чем написать их.
За 15 лет работы с ассемблером мы общими усилиями овладели этим языком так, что он стал языком более высокого уровня, чем все выше перечисленные. Под термином «овладеть языком» я имею в виду не то, что мы досконально знали его синтаксис и семантику, а то, что были наработаны библиотеки подпрограмм, приемы программирования, идиомы и многие специфические приемы, так что программы писались легко и свободно. И, главное, еще легче отлаживались и адаптировались. Те, кто писал на Фортране, оценят последние свойства. Именно за эти годы мною и моими товарищами по работе под руководством В. Арлазарова были написаны «Каисса», «ИНЕС», АСУ МНТС (Международного научно-технического сотрудничества для ГКНТ СССР) и много конкретных прикладных систем. Где-то в это время нам пришлось расстаться с привычными перфокартами и пересесть за дисплеи, между прочим, – алфавитно-цифровые.
Сделанная в ИПУ «Каисса» стала первым чемпионом мира среди шахматных программ. Кроме удовлетворения амбиций, она принесла мне еще много друзей по всему миру, поскольку в те времена создание хорошей шахматной программы было делом сложным, и сформировался своего рода теневой клуб авторов и знатоков шахматных программ. Среди них были знаменитые в мире информационных технологий люди – К. Шеннон (автор теории информации), К. Томпсон (автор операционной системы Юникс), Д.Леви, М. Ньюборн, А. Марсланд, Б. Миттман, Ф. Фридель (автор ChessBase) и многие другие.
С Клодом Шенноном связана одна из самых удивительных историй в моей жизни. Меня с ним познакомили в 1980 году на чемпионате мира среди шахматных программ в Линце.
Каждый чемпионат имеет своего почетного гостя, и в том году им был Клод. Услышав его имя, я подумал «Как! Он еще жив?». Ведь работы Шеннона по шахматному программированию относились к году моего рождения, то есть для меня он существовал в давнем прошлом. Оказалось, что ему в год моего рождения было меньше тридцати, и в 1980-м он был далеко не старым человеком. Когда пришла моя очередь быть почетным гостем чемпионата мира 1999 года в Падерборне, я прочел в глазах молодых шахматных программистов все тот же немой вопрос «Как! Он еще жив?». И, поняв, что с момента моих публикаций уже прошло больше двадцати лет, я вспомнил Шеннона и успокоился.
В начале 1970-х появились машины серии «Ряд». Так получилось, что во время моего распределения после МГУ мне пришлось быть свидетелем, как А.С. Кронрод боролся за продолжение проектирования и производства оригинальных советских машин (он даже предлагал назвать серию «АС» — автоматическая советская — по своим инициалам) против В.М. Глушкова и Л.Т. Кузина, которые ратовали за копирование IBM. Одним из аргументов у последних было то, что можно будет воспользоваться всем математическим обеспечением, созданным для IBM и ликвидировать то небольшое отставание в вычислительной технике, которое имелось в конце 1960-х.
Глушков и Кузин победили — судьей был председатель ГКНТ Кириллин, но все оказалось не так-то просто. Первый компьютер серии титаническим трудом инженеров-электронщиков был запущен в 1972 году, а массовая работа на нем началась только в 1979 году. Все это время я неплохо зарабатывал лекциями по ОС ЕС ЭВМ. Документация по системе переводилась моими однокурсницами и другими людьми, не представлявшими себе, что такое компьютер вообще и операционная система в частности, и разобраться по такой документации было невозможно.
Глушков и Кузин просчитались именно в культуре пользования. Теперь я понимаю, что неправ был и Кронрод, за которого я «болел», потому что надо было и копировать IBM и делать свои машины именно для сохранения культуры. А в итоге к 1980-м мы потеряли культуру проектирования элементов, потом и культуру проектирования устройств, а сейчас от нас уходит (вместе с носителями – людьми, которые умеют это делать) культура создания операционных систем. В итоге, вместо того, чтобы догнать кого-то, мы отстали в этих компонентах навсегда. И, повторюсь, не потому, что нет нужных производств или знаний, а потому, что почти не осталось людей, которые это умеют делать.
А в 1980-х началась эра языка Си на машинах, скопированных с PDP и IBM PC. Мы потеряли весь свой ассемблерный «языковый запас» и не достигли аналогичного уровня инструментария на Си. Это была своего рода эмиграция. Привыкнув к детальному пониманию, как происходят реальные вычисления в памяти, пришлось отвыкать и работать в гораздо более абстрактных сущностях. Зато остался интерес к базовым понятиям программирования, выходящим за пределы конкретных языков, операционных систем и устройств. Как любят говорить мои сотрудники «В конце концов, в компьютере биты бегают».
Одним из важнейших принципов программирования для меня является необходимость создания собственного инструментария для любого проекта, начиная с проектов средней величины. Это мы красиво называли «созданием специализированного (для проекта) языка программирования», включавшего специфичные структуры и классы данных и базовые процедуры. Крупные проекты требуют параллельной разработки специфических (для проекта) отладочных средств. Все это не исключает, а даже предполагает создание абстрактных библиотек, а также инструментальных и отладочных средств, используемых во всех проектах. В сущности, только последнее и делает ремесло программиста или разработку фирмой программ прибыльным делом.
Есть общие методические принципы создания программ, не вполне осознаваемые даже хорошими программистами. Примером может служить проблема принадлежности объектов друг другу, а также совмещение двух структур любой программы – иерархии вызова подпрограмм вместе с объектами, принадлежащих подпрограммам, и иерархии объектов по принадлежности друг другу. Примером отказа от самой идеи справиться с этими проблемами является наличие в некоторых языках механизма сборки «мусора», что является молчаливым признанием возможности присутствия в среде объектов, не принадлежащих ни подпрограммам, ни другим объектам. С другой стороны, система счетчиков использования объектов давно известна, но применяется она в основном только для объектов, которые могут принадлежать нескольким владельцам.
Создание собственного языка программирования и отладочных средств для конкретного проекта оказало решающее влияние в победе «Каиссы» на первом чемпионате мира среди шахматных программ. Большая часть программы была написана в терминах операций над «досками» — 64 битными объектами, которые задавали булево значение одновременно для всех полей доски. Эффективная реализация таких операций и их использование в алгоритмах позволили реализовывать сложные решающие правила за приемлемое время.
«Система наблюдения» «Каиссы» давала возможность вывода на печать хода перебора в любом разрезе, начиная с любой точки, как в партии, так и в переборе. Что важно, сама форма выдачи была «человеческой», то есть в шахматных терминах, а не в терминах программы. Во время матча «Каиссы» с читателями «Комсомольской Правды» в 1972 году результатом каждого хода была распечатка толщиной 2-3 сантиметра. И мы ее всю внимательно прочитывали. Поэтому к чемпионату мира мы знали о глубинах перебора гораздо больше, чем все остальные. В этих условиях было трудно не придумать эффективные методы сокращения перебора, которые и принесли «Каиссе» победу. Кстати, в научных кругах, матч 1972 года ценится гораздо выше, чем победа в чемпионате мира.
С течением времени программирование из тонкого ремесла, иногда восходящего к искусству, становилось ремеслом все более и более рутинным. Если до середины 1980-х еще реальны были программы, созданные если не одним человеком, то хотя бы в рамках одного коллектива, то в дальнейшем в производство шли программы, построенные по принципу «Лего», а именно, собранные из различных полуфабрикатов (библиотек и компонент), разработанных в разных уголках мира. Как ни странно, это сделало ценность программистов с хорошим математическим (не скажу образованием, а подходом) гораздо выше. Их стали называть по-разному – системными аналитиками, руководителями проектов, системными архитекторами.
И наряду с программистами, умевшими «выполнить проект» — реализовать конкретное техническое задание, потребовались именно такие «абстрактные» специалисты, умевшие совсем другое: разбить процесс создания большой системы на проекты, выбрать для них инструментарий, подобрать исполнителей, суметь их проконтролировать и, в конечном счете, обеспечить работоспособность созданной системы. И сегодня таких специалистов приблизительно столько же, сколько было программистов в начале моего трудового пути. Только просьба не путать системных архитекторов и системных администраторов.
Эти две почетные профессии не имеют практически ничего общего. Более того, мой короткий опыт работы, близкой к системному администрированию, показал мою полную профнепригодность в этой области. С другой стороны, мне неоднократно удавалось проектировать и внедрять большие системы.
Проблема выбора инструментария для создания большой системы является одной из ключевых. В прежние времена стандарты на компоненты и их описания были столь слабыми, что проще было написать свое, чем пользоваться чужим. Сейчас усилиями крупных фирм по созданию программного обеспечения, в первую очередь, усилиями Майкрософта, этот процесс стандартизовался, и пользоваться чужими компонентами стало легче. Другой вопрос, что большинство доступных компонент далеки от идеала, но плохой стандарт все равно лучше, чем его отсутствие. Однако инструментарий инструментарием, но приходится выбирать алгоритмы обработки информации, и иногда ограничения на их трудоемкость влияют на размер решаемых задач, а, значит, и подходов. Здесь мой опыт семинара по эффективным алгоритмам и, особенно, опыт работы над шахматной программой, сыграл существенную роль. Как говорил мой соратник А. Усков, «после шахматной программы все задачи кажутся простыми».
Поскольку главным при создании сильной шахматной программы являются эффективные алгоритмы перебора вариантов, то у меня нет страха перед применением перебора для решения любых задач. Там, где обычный программист оценивает трудоемкость как безнадежную, умеющий строить эффективный перебор легко решает сложную задачу. Основой для эффективного перебора, который я, с большей или меньшей интенсивностью, использую всю свою профессиональную жизнь для самых неожиданных вещей, является накопление информации по ходу перебора и использование ее для сокращения перебора в аналогичных обстоятельствах. Поскольку обычно перебор состоит в многократных попытках переставлять одни и те же звенья в единую цепь, то результаты такого подхода бывают поистине удивительными.
В качестве примера могу привести систему пользовательского интерфейса для задачи взаимодействия с большим количеством объектов. Одной из ключевых проблем такого интерфейса является определение объекта, который пользователь имеет в виду, нажав кнопку мыши. Традиционный метод состоит в том, чтобы каждому объекту поставить в соответствие прямоугольник, и обращаться к тому объекту, в чей прямоугольник входит точка нажатия мыши. Наш подход был основан на определении понятия расстояния от точки нажатия мыши до каждого объекта и переборе всех объектов для нахождения ближайшего.
Возьмем для примера букву «О», в одном случае лежащую на «пустом» месте, а в другом — на фоне буквы «П». Нажатие мыши внутри «О» при традиционном подходе всегда приведет к взаимодействию именно с ней, а при нашем – к взаимодействию с буквой «П» или «О» в зависимости от того, попал пользователь в букву «П» или нет. Замечу, много моих коллег по работе над задачами искусственного интеллекта потом переключилось на работу с системами пользовательского интерфейса. По всей вероятности, это связано с тем, что нам нравится решать сложные задачи с реальным, легко проверяемым результатом.
Вернемся к 1980-м. Еще до перестройки мы локально победили академическую бюрократию за счет того, что на игольчатом принтере «Электроники» смогли изобразить шрифт печатной машинки. В то время, например, было запрещено подавать к защите диссертации, напечатанные на компьютере, но с нашим шрифтом понять, что это печать компьютера, а не машинки, без специальной экспертизы было нельзя. Аналогичным образом дело обстояло со многими другими документами – планами, отчетами, выездными характеристиками и так далее.
До создания этого шрифта любой бюрократ находил повод придраться к документу из нескольких страниц и требовал его перепечатки, получая передышку на пару часов, а то и дней. Но после создания шрифта исправленный документ ложился ему на стол через пять минут, и он понимал, что ищет работу не мне, а себе. Тут-то в документе все волшебным образом становилось нормальным. Что он при этом думал о моей квалификации как машинистки, остается тайной.
В начале российской эпохи персональных компьютеров, случайно или не случайно совпавшей с кооперативным движением, ко мне обратился прекрасный менеджер Е. Соколинский, возглавлявший кооператив «Перспектива» с предложением реанимировать «Каиссу» для ПК. Для этого мне нужно было из работавшего в свое удовольствие ученого стать начальником группы программистов, да еще и создать эту группу с нуля. Уговорив меня, Соколинский нашел изумительный способ формирования группы. Мы дали объявление в газеты о платных курсах шахматного программирования. Стоимость месячного обучения для наших слушателей составляла 200 рублей, что по тем временам была существенная сумма. Занятия шли шесть дней в неделю, и кооператив доплачивал за аренду аудиторий и компьютеров немалую сумму. Потом мы всей группой перешли в СП «Параграф».
В конце 1980-х, когда я оказался в СП «Параграф», предприятие представляло собой своеобразную сборную лучших московских программистов. В «Параграфе» того времени работали Е.Веселов (автор «Мастера» и «Лексикона»), А. Чижов (автор многих русификаторов, в частности, знаменитой «Беты», он же автор альтернативной таблицы кодировки кириллицы) и другие. В качестве помощницы у Веселова в «Параграфе» работала О. Дергунова, получившая известность уже в Майкрософте. Игры продавал В. Савюк, потом раскрутивший марку «Денди». В общем, компания подобралась неплохая.
По дороге пришлось пережить очередной крутой поворот – появилась операционная система Windows 3.1, и пришлось от традиционного процедурного программирования переходить к системам, управляемым потоком событий. Сегодня они привычны и понятны, а тогда ушло много усилий на понимание «куда лошадь запрягать», а именно — как устроен порядок исполнения кода в таких системах. Поток управления в них весьма неочевиден, и проблемы многопоточности и синхронизации вышли на первый план.
У меня в «Параграфе» был отдел шахматного программирования, в котором «Каисса» получила вторую жизнь в качестве программы для IBM PC. Хотя мы и сделали в отделе шахматную программу – реинкарнацию «Каиссы» для IBM PC, которая достойно сыграла на компьютерной олимпиаде 1990 года, заняв третье место, интерес быстро сдвинулся в сторону пользовательского интерфейса, поскольку графические оболочки Мака и Windows очень манили в эту сторону.
Наш отдел, в котором работали А. Дубец, М. Караев, В.Кокин, И. Шабалин и другие, открыл целое направление графических редакторов. Мы сделали редактор формул, а, уже уйдя из «Параграфа», редактор факсов, а потом и новую версию Лексикона. Оказалось, что общее всех этих редакторов – разбиение на данные, их отображение и собственно редактор, преобразующий данные согласно действиям пользователя, является фундаментальным для систем пользовательского интерфейса. Недаром операционная система Symbian базируется на таком разбиении.
В это же время пришлось осваивать язык C++. Мое знакомство с ним началось с экскурсии в офис Bell Laboratories в Murray Hill, которую мне устроил в 1989 году автор Юникс Кен Томпсон. Мы с сыном жили у Кена в гостях, и в воскресный вечер он предложил прокатиться в офис. Офис был безлюден, и я с интересом смотрел на технические чудеса, которых там хватало. В какой-то момент Кен показал на дверь кабинета со словами «А здесь сидит чудак, который думает, что на его языке будет программировать весь мир». Табличка на кабинете гласила, естественно, «Б. Страутсруп».
Потом пришлось-таки учиться программировать на C++. Язык очень коварен. На нем должны программировать либо начинающие программисты, которым важно быстро получить результат любыми средствами, либо очень опытные. Создание больших систем на C++ программистами среднего класса может приводить к самым печальным последствиям. Однажды в книжном магазине Стэнфордского университета я видел книжку по C++, напоминавшую сборник кроссвордов. Там приводилось множество выражений на C++, выглядевших очень естественно, но транслировавшихся в умопомрачительный набор команд. Зато C++ позволил вернуться к эффективному созданию инструментальных средств. Наборы идиом, библиотечных классов, правила пользования — все это стало багажом наших программистов, сделав их работу более легкой и приятной.
После ухода из «Параграфа», я не смог найти другую работу по принципу «двух медведей в одной берлоге», когда начальник не хотел иметь в команде еще одного лидера. Поэтому в 1994 году мне пришлось заняться бизнесом, организовав свою фирму — «ДИСКо» (Donskoy Interactive Software Company), существующую по сей день. Фирма занимается разработкой программ на заказ. Основными клиентами являются крупные компании, работающие в области информационных технологий. Связано это, в первую очередь с тем, что доказывать разумность нашей ценовой политики клиентам из других отраслей крайне сложно. Они искренне полагают, что любую программную систему можно сделать одному человеку за месяц. Ситуация усугубляется тем, что рынок полон дешевых предложений, связанных либо с самонадеянностью вчерашних студентов, либо, что еще хуже, с сознательным затягиванием клиента с целью дальнейшей раскрутки его уже на совсем большие деньги. Это напоминает «бесплатные» лекции по народной медицине, где вход формально свободен, а выход — фактически с пустым кошельком.
Фирмы в отрасли информационных технологий более адекватно оценивают и стоимость работ, и их исполнителей. Рынок наш небольшой, все фирмы на виду, репутации известны. Известны, к сожалению, только внутри отрасли. Тем не менее, заказов хватает.
До кризиса доткомов «ДИСКо» работало в основном на рынке США, но после него пришлось переориентироваться на российский рынок. В Америке ни один менеджер не ведет переговоры вне рамок своей компетенции и, особенно, вне рамок своего бюджета. В России, особенно на первых порах, много раз приходилось, уже придя к соглашению по всем параметрам проекта – техническим требованиям, цене, срокам, слышать замечательную фразу: «А теперь я пойду согласовывать это с начальством». Эффективность переговоров с такого рода менеджерами, мягко говоря, невелика. Отсюда нацеленность «ДИСКо» работать с крупными кампаниями, про которые ясно, кто есть кто.
Что мы получаем, переезжая в другую страну? Мы сразу же опускаемся на много ступенек социальной лестницы. Немедленно. Одно дело отлично говорить по-английски и понимать, как устроена американская культура, а другое дело — жить в ней. Не так подарил цветы, не так ответил на письмо, и вот ты уже слон в посудной лавке. Если человек прожил двадцать лет здесь, он никогда выше определенного уровня не поднимется там просто потому, что не сидел рядом на горшке с выпускниками Гарварда, не учился с ними в одной школе. Мы все читали в книжках про клубы в университетах, но не понимаем, насколько они важны. У меня много американских друзей, и я вижу наших эмигрантов их глазами. Так что слон в посудной лавке — это самое мягкое, что можно про них сказать.
Когда Мао Цзедуну говорили, что китайские специалисты уезжают, он отвечал: «Куда бы они ни уехали, они останутся китайцами». Нам вот этого не хватает. Эта дурацкая советская традиция считать уезжающих предателями и вычеркивать из нашей культурной ауры. Давайте сформулируем вопрос иначе. Скажем, не «как удержать человека в стране», а «как удержать его на фирме»? Рабства давно нет. Если условия, которые предлагает фирма, сотрудников не устраивают, они уходят. Но увольнение по собственному желанию не есть предательство. Это нормально, это его право. И обязанность фирмы уважать это право. Если же человека попрекать, «ах какой ты нехороший, ты уходишь из компании», то он уйдет навсегда. То же и со страной.
Впрочем, наши мало возвращаются. И дело здесь не в плохих условиях жизни в России, причина чисто культурная. Наши люди очень не любят менять место жительства, работы. Смотришь и диву даешься. Работает человек в государственном институте, где давно ничего не платят. Почему работает? Ему лень с места тронутся. А уж вернуться обратно на родину еще сложнее. Второй раз в жизни все менять очень тяжело. Да еще семья…
Тамошний временной стресс нам непонятен. У нас — расслабленное состояние на кухне, курилка, пятничные выпивки, характерные для многих программистских компаний. А когда работаешь в Америке, в первую же пятницу садишься вечером на койку и думаешь: «какое счастье, что завтра суббота». Такого ощущения счастья в России никогда не бывает. Там тебя выжимают, как мочалку, еще стряхивают после этого и бросают. И американцы с этим живут каждый день. Если спросить, какого человека поставить на конвейер, американца или русского, я сто раз из ста скажу: американца. А если делать Василия Блаженного, то те же сто раз я скажу: русского. Потому что это совершенно разные вещи — писать код и уметь работать в команде, уметь быть организованным, думать о том, чтобы твой код вливался в код еще ста человек.
Бывает, во время выполнения заказа вам в голову приходит гениальная идея. Если вы будете реализовывать ее в рамках заказа, будет плохо и вам, и заказчику. Вам — потому что интеллектуальная собственность на идею отойдет заказчику. А ему… Ну, представьте, выполняем мы заказ, допустим, для «Боинга», и придумали, как организовать компьютерную память. И что, «Боингу» теперь памятью торговать? Если же я скажу, знаешь, «Боинг», меня посетила идея, и я сделаю заказ на полгода позже, будет просто истерика. Поэтому лучше эту идею положить в карман, подождать, пока кончится заказ, а потом продавать ее, как отдельный продукт.
Чего не хватает российским фирмам? Хорошего портфолио выполненных заказов. Для выхода на этот рынок надо убедить заказчика, что, работая с тобой, он ничем не рискует. И если это удалось, если между вами установилось доверие, заказчик захочет иметь вас «при себе», потому что искать другого надежного исполнителя — дорогое удовольствие. Для фирм поиск исполнителей — такая же головная боль, как для нас — поиск заказчиков.
Продажи, конечно, важны. Но продавцы продавцами, а рано или поздно дело доходит до первых лиц компании, если речь идет о крупных контрактах. И всегда разговор начинается с брачного танца: кто ты, кто я, знаешь ли ты такого, а слышал ли ты об этом. Казалось бы, зачем нужна огромная выставка «Comdex» в Лас-Вегасе? А вот зачем. Если Билл Гейтс придет в гости в Symantec, про это узнают все, это будет скандал. Если же Гейтс во время выставки поднимется не на свой 15 этаж, а на 18-й, где живет президент Symantec, никто об этом никогда не узнает. Ради того все и сделано. Крупный контракт — это риск заказчика. Эти брачные танцы — не зря. Потому что потом заказчик позвонит общим знакомым и спросит: «А что ты думаешь об этой фирме, имел ли ты с ней дело?». Никуда от человеческого фактора в бизнесе не денешься.
В начале этого тысячелетия пришлось сделать еще один крутой поворот, на этот раз — в сторону мобильных устройств и всего, что с ними связано, в первую очередь, беспроводными технологиями связи. Поскольку первые заказы были американскими, приходилось убеждать авторов технологий в их «незрелости» для практического использования. Слышать это от маленькой российской фирмы им было странно. К счастью, это потом подтверждалось и другими, более авторитетными источниками. Так было, например, с технологией BlueTooth, которую много критиковали.
Мы сделали пилотный проект для разных средств связи по заказу 3COM, и, если инфракрасная связь и WiFi работали прекрасно, то с BlueTooth были серьезные проблемы. Однако с 2004 г. с BlueTooth стало все в порядке, а мобильные устройства становятся все популярнее и популярнее. Хотя карманные компьютеры и сходят на нет, их с успехом заменяют (а может, и вытесняют) смартфоны, имеющие все прелести и карманных компьютеров, и мобильных телефонов. Для лэптопов и ноутбуков сейчас тоже очень хороший сезон. А впереди маячили планшетные компьютеры и сетевые, и многое другое.
Весь этот зоопарк мобильных устройств объединяет одно существенное свойство – умение работать вдали от офиса. И тут интересно заметить, как многолетнее желание иметь компьютер всегда на связи с Интернет входит в противоречие со способом пользования мобильным компьютером. Дело не только в том, что пройдет еще существенное время, когда Интернет будет доступен отовсюду – из самолета, из далеких стран и много еще откуда, где он сейчас не доступен, но и в том, что инструментальные средства Интернета (браузеры и встроенные в них объекты) не слишком пригодны для многих практических нужд. Например, заполнение в Интернете формы из нескольких страниц, особенно, если последующие страницы зависят от полей предыдущих, хотя и возможно, но слишком часто приводит к неудачам, как вследствие ошибок заполнения, так и вследствие обрывов связи.
Мы прочно стоим на идеологии сеансовой связи. Она состоит в том, что клиент (мобильный компьютер) связывается с сервером только время от времени, синхронизуя данные в обе стороны. Изысканные схемы обмена могут строиться так, что клиенту передаются только те данные, которые нужны на ближайшее время. Примером может служить сеанс связи руководителя предприятия перед поездкой к партнеру. Во время этого сеанса можно загрузить на мобильный компьютер всю информацию о взаимоотношениях с этим конкретным партнером – договора, сделки, расчеты – и иметь ее под рукой во время переговоров.
Идеология сеансовой связи воспринимается заказчиками не сразу, но постепенно они оценивают все преимущества такого подхода. Возможность выбора способа доступа к серверным данным, скорость передачи и объем передаваемой информации, удобство и эффективность работы с данными на мобильном устройстве – все это делает такую идеологию весьма привлекательной. У нее есть один недостаток – нужна предустановка клиента на мобильное устройство, но преимуществ всеже больше.
В области мобильных устройств ярко проявилось преимущество Майкрософт в подходе к созданию операционных систем над всеми остальными. Десять лет назад самым распространенным мобильным компьютером был Палм. И хотя мобильная версия Windows уже существовала, казалось, что она никогда не сможет быть использована из-за непомерных требований к ресурсам мобильных компьютеров. А Палм был на коне, поскольку для него была специально разработана минималистская операционная система, в которой даже не нашлось места нормальной файловой системе. Одна беда: программировать для такой системы было непривычно и крайне непросто. В итоге серьезных программ для Палм так и не было создано, он так и остался еженедельником, а не компьютером. А к 2003 году мощность карманных устройств доросла до мобильного Windows, и, откуда ни возьмись, масса программистов стала делать большие программы для этой системы. Идеология мобильного Windows была понятна и привычна для программистов Windows для ПК. В итоге операционная система Палм сошла со сцены, и скоро за ней уйдет и само устройство.
Похожая история должна произойти с Symbian, операционной системой, установленной на телефонах Nokia и Sony Eriicsson. Подход ее авторов тоже был минималистским. Она, конечно, лучше, чем Палм, но все равно, крайне трудна для программистов. А именно программисты решают все. Самой лучшей операционной системой последние 30 лет является Юникс, но плохой пользовательский интерфейс привел к тому, что более популярно изделие Майкрософта. Кроме того, программисты, пишущие для Юникса, имеют весьма специфический характер. Их почему-то больше волнует идеологическая чистота системы, чем ее преимущества для пользования. Однажды я работал с «юниксоидом», делавшим серверную систему для салона игровых автоматов. На все мои требования сделать возможной выдачу статистики игр, он отвечал, что это уменьшает безопасность системы. То, что в данном случае гораздо большую опасность представлял собой вульгарный сговор персонала с игроками, против которого и нужна статистика, его не волновало. Видимо, в книгах по Юниксу это нигде не написано.
Сила Майкрософта не только в больших деньгах, вкладываемых в раскрутку продуктов, иногда не совсем работающих, но и в армии программистов, умеющих работать в этой системе, и в куче полуфабрикатов, которыми они могут пользоваться. Для меня, например, разработка программы для Windows по себестоимости вдвое дешевле, чем разработка аналогичной программы для Symbian. Нетрудно догадаться, какую систему я рекомендую своим заказчикам.
Пока последний поворот в моей программистской биографии – видео в Интернет. Мировая паутина – это особая тема для разговора. Она обладает врожденным пороком: это система, придуманная для обмена гипертекстовой информацией в распределенных сетях. Однако за свои 13 лет, начиная с появления «Мозаики», паутина эволюционировала в сторону системы доступа к гигантскому хранилищу информации. С развитием сетей связи характер информации в паутине стал резко меняться. Если сначала это была легко отформатированная текстовая информация, то потом стали внедрять изображения, движущиеся изображения, а в последнее время и видео.
Настоящие проблемы начались с того, момента, когда потребовалась серьезная интерактивность, в начальный стандарт не заложенная. Поэтому под разными масками в статическую информацию стали добавлять программы. Это могут быть интерактивные объекты, флэш, загружаемые программы, что угодно… В итоге получился суп из топора.
Сегодня принятый как стандарт формат представления информации в Интернет — HTML является сдерживающим фактором для построения интерактивного контента. Но, как и в случае с левосторонним автомобильным движением, сменить его крайне трудно. Ведь можно потерять накопленную за десятилетие информацию, да и пользователей так быстро на новые браузеры не переведешь. Поэтому создание порталов и сайтов с видеоконтентом является непростой задачей не только с информационной, но и с программистской точки зрения. Фактическое отсутствие стандарта и наличие многих разношерстных инструментальных средств, решающих одну и ту же задачу – доставку видео и его отображение в браузере, делает эту задачу поистине творческой в самом плохом смысле этого слова.
Подводя итоги, я хочу показать, как логика развития информационных технологий изменила характер моей профессии. Говорить о профессии программиста можно, но она столь же неконкретна, как и профессия строителя. Давайте сравним русских строителей с американскими. Те построили «Эмпайр-Стейт-Билдинг», а наши — храм Василия Блаженного. Программист — профессия многогранная. Есть системный программист, есть архитектор систем, есть кодировщик, как в строительстве — там есть прораб, а есть подносчик цемента.
Мы обладаем одним большим преимуществом — солидной математической подготовкой, логическим мышлением. Плюс у нас определенная свобода в отношении ко времени. Время мы и американцы воспринимаем очень по-разному. На них оно постоянно давит. Наш человек более расслаблен. Первые пять лет работы никто у нас не находится под стрессом. Эта расслабленность имеет свои плюсы потому, что те гениальные идеи, которые могут прийти российскому программисту, американцу, скорее всего не придут.
Строитель, который вытачивает головки храма Василия Блаженного, это одно, а строитель, который краном поднимает блоки для сорокаэтажного здания — совершенно другое. И думаю, что слова о шикарных русских программистах — всего лишь слова. Мне как-то рассказывали на фирме Sun, что когда в 1995 году оставалось три дня до сдачи «Соляриса», им нужен был тест для Фортран-транслятора. Послали в Новосибирск заказ (у Sun была там своя группа) — сделать за два дня тест. Через неделю получили ответ, что через месяц будет замечательный тест на все случаи жизни. Вот вам разница культур. Человек, кладущий кирпичи, и человек, создающий большие архитектурные проекты, в равной степени могут называться строителями, но это абсолютно разные профессии. В моем возрасте класть кирпичи уже неэффективно – не хватает скорости мысли, но, с другой стороны, опыт работы позволяет абстрагироваться от мелочей и рассматривать проблемы с системной точки зрения. Для моих американских коллег такой подход очевиден, здесь же многие считают его верхоглядством.
Я давно считаю само собой разумеющимся, что смогу реализовать любой алгоритм. Я имею довольно большой инструментальный набор и знаю, каким инструментом когда пользоваться. Мне не приходится задумываться над тем, как писать циклы, и так далее. Все это дает возможность, думая над программой, делать это с другого уровня.
Приходящая же в профессию молодежь, не имеет такого запаса, и не столько потому, что глупее, а потому, что их не так учат. В моей молодости обучение программированию в институтах было вообще смешным – изучались только синтаксисы разных языков на простейших программах. Сейчас дело обстоит чуть получше, но я не слышал, чтобы во время сдачи курсовой или дипломной работы студенту на ходу меняли техническое задание. А мне в жизни приходилось, сдавая большую систему, с удивлением узнавать об изменении формата входных данных. Я считаю такую ситуацию нормальной, а молодые программисты – издевательством. Почти все учащиеся ВУЗов решают сделать дипломную работу на заказ из-за того, что такая работа требует много времени для ее подготовки.
Размер дипломного изыскания может быть или от 50 до 80-100 страничек. Могут быть и другие требования, которые зависят от конкретного учебного заведения. Они не понимают, что если заказчик меняет требования к уже почти готовой системе, это означает, что система ему нравится. Если система ему не нравится, он вздохнет, заплатит за нее и про нее забудет.
Начинающим программистам, прежде всего, нужно математическое образование и английский язык. Всему остальному можно научить. Хотя выпускники и так приходят достаточно подготовленными. Сегодня мало-мальски образованный ребенок не может вырасти без компьютера. Поэтому работодателю ориентироваться на специальные вузы, мне кажется, не стоит, гораздо важнее общая культура человека, особенно математическая. Или, опять-таки, умение работать в команде — оно гораздо важнее, чем курсы, которые ему читали в техническом вузе.
Все молодые ребята, приходящие ко мне, обладают одним и тем же недостатком. Они устремлены к тому, чтобы их часть программы заработала как можно быстрее, думая, что это – успешный конец работы. Никто до меня их не научил, что работающая программа – это только начало. Дальше, в ходе ее использования, будут возникать все новые требования, и программу придется непрерывно менять. Поэтому изначально в нее должна быть заложена эластичность, без которой вносить изменения в программу будет крайне сложно. Кроме того, инструментальные средства, которые они используют, становятся все более крупными, и мало кто понимает, как эти средства организованы внутри, по каким принципам они работают. Этого и не требуется, если нужно только чуть-чуть подстроить такие средства, но при создании больших систем отсутствие такого понимания может вести к большим проблемам, начиная с неэффективности и кончая полной неработоспособностью.
Понять внутреннюю организацию сложных систем можно только одним способом – самому сделать что-то подобное, пусть и гораздо более простое. Но я не слышал, чтобы студентам задавали в качестве курсовой работы создание простой операционной системы или системы управления базами данных. В итоге профессия программиста меняет свой характер. Если раньше программисты знали свою программу досконально, то теперь, в лучшем случае, они умеют эффективно использовать то или иное инструментальное средство. Появились вообще странные на мой вкус термины как программисты на PHP и HTML.
Я пишу эту статью к своему 60-му дню рождения, возраст пенсионный, и, похоже, кончается не только мой жизненный цикл, но и жизненный цикл той творческой профессии, которой я занимался всю жизнь, и которая называлась профессией программиста. Сейчас профессия осталась, но, как и профессия шофера, она не требует творчества и особых знаний, а только определенных навыков. Программирование из искусства становится ремеслом, и я счастлив, что всю жизнь занимался программированием, пока это было так же интересно и почетно, как пилотировать самолеты во времена Экзюпери.
Пголит.ру
Август 2008 г.
Москва
