В марте 1983 года Сапожников попросил меня сводить на Столбы столичного гостя. Вообще-то такая халява - в рабочий день сходить на Столбы, должна была отвалиться Качаеву, который был походником куда лучше меня - но Качаев почему-то не смог. Судьба постаралась, чтобы это был именно я, и я не считаю это случайностью.
Гость, Саша Ковалёв, и впрямь был из столицы, только не из Москвы, а из Киева, из Института кибернетики АН УССР. Поэтому мы сначала поговорили о Киеве, в который я влюбился три года назад. А потом - о Красноярске. Гость завидовал: у нас тут есть всё: и реки для сплава, и пещеры, и горы для горных лыж, и скалы для скалолазания.
Уже потом выяснилось, что гость - программист. Само собой, пошла речь о технологии программирования. Ковалёв рассказывал какие-то совершенно фантастические вещи о неизвестной мне доселе Р-технологии программирования.
Я тоже был не лыком шит и рассказал о "хирургической бригаде" (мы три месяца назад успешно сдали TABL), решениях, которые мы применили на "Дельте" и о I-System.
Не сказать, чтобы Столбы мы пустили побоку, но в нашем общении они заняли отнюдь не первое место. Я, вообще, впервые видел человека, который в вопросах технологии программирования понимает меня с полуслова. Да и Ковалёв не ожидал увидеть в Красноярске людей, убежавших впереди паровоза. Дело кончилось тем, что я получил приглашение в ИК АН УССР им. В.М.Глушкова на семинар в отдел технологии программирования (оказывается, существовал и успешно работал целый отдел, который решал те самые задачи, от которых пухла моя бедная голова!).
Вскоре я приехал в Киев и выступил. Дебют обернулся бенефисом. Мы разговаривали в отделе до позднего вечера, потом пошли куда-то в кафе, из кафе в гости к кому-то (кажется, к Сереже Лизенко). Заходил на семинар на часок и академик Вельбицкий. Вельбицкий слушал весьма благосклонно, лишь изредка иронично улыбаясь - когда я рассказывал о потугах по созданию проектной документации, иногда одобрительно кивая - когда речь шла о о хирургической бригаде.
А наутро уже хозяева принялись удивлять меня. Мне показали только что выпущенные ДВК-2, на которых ушлые киевские кибернетики уже разрабатывали версию РТК. Мне показали проспект американской персоналки Lisa, которую я, признаться, не оценил. Но зато оценили хозяева - для их Р-технологии, алфавитно-цифровые дисплеи в 24 строки по 80 символов были сильнейшим тормозом развития. Они жаждали графических дисплеев и развитых средств диалога, и я уже понимал почему.
Р-технология - это была вещь, которая потрясла меня до основания. Все передовые идеи того времени - от структурного и модульного программирования до управления коллективом разработчиков и совершенной проектной документации, встроенной в тело программ и бывшей их неотъемлемой частью (нет, речь идёт не о комментариях к операторам - о гораздо и гораздо большем!). Всё это к тому же было упаковано в совершенно новую графическую форму - Р-графы.
Казалось бы, графическое представление программ - не редкость. Сейчас даже в школах учат составлять блок-схемы. Однако блок-схема стоит на понятии перехода, то есть на GO TO, и изначально не структурна и воспитывает неправильный, процедурный стиль программирования. Чтобы составлять структурные блок-схемы, нужна определённая культура и определённое самоограничение.
Киевляне вывернули блок-схемы наизнанку: вместо графов с нагруженными вершинами стали использовать графы с нагруженными рёбрами. Вот так, например, выглядит конструкция ЕСЛИ ТО ИНАЧЕ в блок-схемах и Р-схемах:
Таких конструкций было всего четыре: IF THEN ELSE, REPEAT UNTIL, DO WHILE. CASE OF, т.е. полный набор структурных конструкций. Неструктурный переход программист не мог сделать, потому что его не было в принципе. Все конструкции представлялись вот такими наглядными компактными графами. Конструкции можно было вкладывать друг в друга. Вот так - просто и изящно.
Вторая фишка: программирование шло от данных. То есть, структура данных описывалась теми же Р-схемами. И более того, после того как данные были описаны в Р-схемах, оказывалось, что на самом деле мы получили алгоритм их обработки.
Было и множество других замечательных вещей.
Р-схемы существовали не на бумаге. Они строились в компьютере и отображались на дисплее. Можете себе представить, сколько мастерства понадобилось, чтоб отображать (и редактировать!) графические Р-схемы на алфавитно-цифровых строчных дисплеях! Но с этим справился Сережа Лизенко - суперпрограммист, равных которому я за свою жизнь больше не видел - даже наша красноярская суперзвезда Женя Киперман рядом с ним выглядел бледновато.
Кстати, размер Р-схемы ограничивался двумя экранами. Это было не техническое ограничение, а технологическое: программа размером больше двух экранов плохо понималась даже в Р-виде. Поэтому программист был ВЫНУЖДЕН разбивать систему на небольшие модули. Р-технология насильно ограничивала размеры модуля.
Более того, технология "сверху вниз" была реализована в самом идеальном виде: на верхних уровнях вы над дугами и под дугами писали обычные тексты, то есть это было описание алгоритма. Текст можно было "раскрыть" - то есть породить отдельный модуль, его реализующий. На некотором уровне детализации над и под дугами уже появлялись операторы на языке программирования (например, PL/1). В конечном счёте вся программа была "раскрыта" на языке программирования, и тогда её транслировали (из Р-схем в текст на языке программирования, оттуда обычным путём: трансляция, компиляция, выполнение). То есть Р-язык был некой макронадстройкой над языком программирования, как и мой АС.
Таким образом, содержательный алгоритм и тест программы составляли единое целое. Это было очень сильное решение. Более того, отладку можно было вести ещё на верхних уровнях абстракции, раскрывая тексты модулями-заглушками, которые просто возвращали тестовые параметры. И трасса выполнения программы выдавалась тогда в содержательном виде, текстом!
Но и это ещё не всё. Организация коллектива разработчиков была решена вообще фантастически. Вся работа велась строго в сети (даже если дисплеев на всех не хватало, программисты по очереди входили в свой "личный кабинет"). РТК (Р-технологический комплекс) позволял не только поручать разработку нижестоящих модулей, но и осуществлял контроль исполнения поручений - с выдачей списков поручений по статусам (поручена, начата, сорвана или завершена), с оповещениями о начале и завершении работы и т.п.. Поручив работу, руководитель мог хоть ежеминутно следить за её продвижением, своевременно вмешиваться, если делалось что-то не то.
Любой модуль принудительно содержал блок комментариев, а точнее - описания модуля (при том, что сама Р-схема была прекрасным комментарием).
И так далее. Это была совершенная инструментальная система, заставляющая к тому же разработчиков делать всё технологически правильно: в РТК просто невозможно было разрабатывать системы не "сверху вниз", писать неструктурно, не документировать процесс, и т.п. Всё это работало уже в середине восьмидесятых! И это был такой рывок в будущее!
Для меня загадка - куда всё это делось потом? После 1991 года я ни разу не слышал о РТК. Последнее, что я видел - это редактор Р-схем, реализованный для IBM PC, в 1990 году. И школьники до сих пор рисуют на уроках информатики блок-схемы, на порядок менее понятные, чем Р-схемы. Хотя, казалось бы, с появлением IBM PC , мышек и графических дисплеев эта технология должна была стать новым стандартом. А вот не стала - нет пророков в своём отечестве (пусть даже киевляне к тому времени уже жили в другом отечестве). Возвращаясь к вопросу о прорывах в предыдущей главе: ну ладно, мы там в центре Сибири родили что-то передовое для узкого круга заказчиков. Но ведь ИК АН УССР - это было ФИРМА, это были имена, это был авторитет! Может быть, конечно, что они не сумели пройти через реформы (замечу, что большинство их клиентов были - "ящики"). Но идеи-то, но технологии! Ведь любому, кто хоты бы полчаса поработал с Р-схемами, не захочется возвращаться к блок-схемам! А нынешние инструментальные системы, как мне кажется, уступают РТК как минимум потому, что в РТК весь проект был единым целым - и документация, и код, и иерархия. Они не просто были взаимоувязаны, а именно составляли единое целое.
Увы, и я написал в РТК всего одну программу. Никто не дал бы мне переделать в РТК Дельту (хотя задумки такие имелись). Других проектов не предвиделось. А после ухода из университета я занимался не разработкой, а обучением.
Но однажды меня прошибло-таки: в командировке в г.Калинин занесло меня в кинотеатр, на фильм "Три дня Кондора". И меня потрясло то, что сегодня кажется само собой разумеющимся. На киноэкране герой-шпион пишет какой-то отчет, виден дисплей, и видно, как герой вставляет слово в середину абзаца, а весь текст до конца абзаца СДВИГАЕТСЯ!
Вы скажете - а что тут такого? Но все текстовые редакторы того времени были не абзачно-ориентированными, а строчно-ориентированными (поскольку были предназначены для написания программ, а не обычных текстов). Если ты вставлял слово на какой-то строке и строка не входила в отведенные ей 70-80 символов, то надо было эту строку переломить, а хвост слить со следующей строкой, которую для этого тоже следовало переломить… И всё это надо было проделать "ручками".
В отличие от большинства программистов того времени, я на компьютере писал не только (и даже не столько) программы, но и тексты (например, многочисленные инструкции для пользователей ВЦ, документацию к разрабатываемым нами программам, статьи и тексты спецкурсов. Переламывание строк вымотало мою душу. Понятно, что "Три дня Кондора" произвели на меня столь неизгладимое впечатление. Я немедленно сел писать текстовый редактор, который умел бы так же работать с абзацами, как "кондоровский". И я его написал, в Р-Паскале. Я даже работал на нем пару месяцев на своей ДВК-шке. Но ДВК-2 была медленной машиной, и форматирование абзацев налету здорово тормозило ее работу. К тому же появился нысовский EDIK, который, хотя и форматировал абзацы не налету, а только по нажатию некоторой клавиши, зато имел массу других возможностей, которых у моего редактора не было. Так что "кондоровская" мечта окончательно сбылась года через три-четыре, в Word 2 for Windows.
Я "спелся" с киевлянами потому, что, как и они, считал программирование не наукой или искусством, а производственной деятельностью. Нам виделись фабрики, выпускающие программное обеспечение "на потоке". Однако слепое копирование категорий промышленного производства было ошибкой, и я это чувствовал нутром. Что-то было не так . Я не мог понять, что именно, но интуитивно нащупал одно из самых слабых мест в концепции: производительность труда.
Разумеется, это было самое интересное и самое важное: помимо индивидуальных особенностей программиста (скажем, я в подмётки не годился Сереже Лизенко) интересно было посмотреть, как влияет на индивидуальную производительность труда применение продвинутых технологий, как влияют на групповую производительность труда те или иные организационные решения. Мне интересно было исследовать изменение своей производительности труда - тем более, что у меня не только сохранились тексты всех написанных мною программ, но и было зафиксировано с точностью до минут время, потраченное на их разработку - и не просто время, а с разбивкой по фазам и типам деятельности (проектирование, программирование, отладка, документирование и т.п.). Так получилось, что начало ведения учёта времени совпало с началом моей профессиональной деятельности: первую неучебную программу я начал писать именно в 1976 году (программа составления расписаний). Ну да, была ещё "реальная" курсовая, но это "несчитово" - эта программа не дошла до ЭВМ.
У меня давно руки чесались провести этот анализ. А киевляне меня просто вынудили сделать это. Иметь такие фантастические данные и не воспользоваться, говорили они. И они были правы. Однако для этого надо было ввести данные в компьютер: не руками же всё это считать! АСУ САМ безнадёжно устарела, и летом 1983 года я сделал новую версию - I-System, которая уже использовала индексно-последовательные файлы, ввод и корректировку данных с дисплея (в пакетном режиме - но хотя бы не возиться с перфокартами!). Почти год понадобился на то, чтобы ввести данные за восемь прошедших лет. Понятно, что я вводил все данные, а не только относящиеся к программированию. И, конечно, год - это "футбольное" время, а не "хоккейное". На самом деле в рабочие дни к дисплеям было не пробиться - да и тратить это супердефицитное время на свои нужды было бы нехорошо. Данные вводились в выходные, ночью.
Итак, суммарные затраты времени у меня были. Единица измерения производительности труда программистов к тому времени тоже была выведена Холстедом: количество операторов в единицу времени. И это казалось таким естественным - ну что производит программист, как не операторы? И никто не усомнился в этом, очевидно идиотском, определении. Хотя, уже при первом рассмотрении возникали вопросы: один и тот же алгоритм займёт разное количество операторов на разных языках программирования. Да и в том же PL/1 не совсем ясно, что понимать под оператором. Вот тут и пригодились мои десятилетней давности увлечения теорий измерений (всё пригождается в жизни, даже казалось бы, самое ненужное!), С точки зрения этой теории в методике Холстеда не всё было безупречно, хотя он, конечно, постарался привести всё к одному знаменателю.
Было у меня ещё одно сомнение, к концу эксперимента переросшее в уверенность. Я постоянно участвовал в конкурсах программистов - то в жюри, то участником. Участникам конкурса давалась одна и та же задача, они её решали - на скорость. Учитывалась скорость написания, скорость отладки (т.е. количество заходов), и скорость работы собственно программы. И вот что было интересно: программисты примерно одной квалификации показывали примерно одинаковое время написания, количество заходов (как правило - один-два), и программы работали одинаково быстро, но количество операторов при этом различалось очень сильно - даже на порядок. Помню, однажды первое место заняла программа из десяти операторов, второе - из ста пятидесяти. Делали они ровно одно и то же (по результату), но алгоритмы были разными. Да и Валерий Иванович в своём интервью вспоминает случай, как программу из двухсот операторов ужали до двух!
Тем не менее, кроме методики Холстеда, ничего не было, и я воспользовался именно ею. Результаты меня потрясли, хотя я чего-то такого и ожидал: методика Холстеда - полное фуфло, и дело не в деталях, а в принципе: нельзя измерять объем продукции, производимой программистов, длиной его программы - пусть даже с ограничениями и коэффициентами. Нельзя это делать в принципе! Однако фуфло это уже легло в основу кандидатских и докторских диссертаций, уже были выпущены монографии (автора одной из них помню - Липаев, довелось с ним встречаться на какой-то тусовке, и я пытался убедить его, что он неправ, но он до меня не снизошёл...). А уже, между прочим, собирались внести план по программированию в очередной пятилетний план СССР, и этот план выражался в КОЛИЧЕСТВЕ ПРОИЗВЕДЁННЫХ ОПЕРАТОРОВ!
Тут уместно вспомнить сцену из "Формулы любви", когда кузнецу говорят: сможешь за день карету починить? Без вопросов, говорит кузнец. А за два? Ну, если постараться, и за два, говорит кузнец. А за неделю? Ну ты, барин, и задачки задаёшь, говорит кузнец. Трудно написать короткую программу, а длинную, делающую то же самое - нет проблем! Если бы планы были реализованы, программисты быстро бы освоили истинно советский способ производства ТУФТЫ.
Я доложил результаты в сентябре 1984 года на семинаре по Р-технологии. "Срочно готовь статью" - сказал Саша. И статья вышла в "УСиМ" очень быстро, по советским меркам моментально - через несколько месяцев.
И я стал задумываться том, в чём всё-таки измерять объём продукции, производимой программистом (то, что он производит именно продукцию, я тогда не сомневался).
Вот тут-то моё математическое образование сказало мне: а задача-то вообще, корректно поставлена? Наверное, прежде чем измерять производительность труда, надо определить сущность этого самого труда. То, что это - производство, у меня сомнений уже не вызывало: былые представления о том что программирование сродни научному или даже художественному творчеству, я отбросил: это может ещё как-то относиться к небольшим программам - так ведь, кроме промышленного, существует и кустарное производство - в том числе и художественное. Но разработка серьёзных программных систем - несомненно производственный процесс. Однако, и производство бывает разное, и роль участников бывает разной: и в производстве есть токарь, стоящий у станка, и есть водитель автокара, а можно вообще спутать работника с орудием производства... стоп, я эти слова уже слышал... но где?
А вот где: в том же самом Киеве славная девушка Оля рассказывала мне о науке праксеологии и о её основателе, Тадеуше Котарбинском. А вот и сама книга Котарбинского "Трактат о хорошей работе", которую я купил когда-то, думая, что она - о научной организации труда, и которая стоит много лет у меня на полке. Я, наконец, её с полки снял, прочёл и законспектировал. И, пока я её читал, хлопал себя по ляжкам и кричал: "да вот же оно!".
То, что раньше виделось единственным вариантом, оказалось только одном из множества - и не самым лучшим. Из всех видов производства для "перенесения в программирование" было выбрано только одно: машиностроительное, и из всех деятельностей в машиностроении была выбрана всего одна: конструкторская. А если деятельность ближе, допустим, к химическому производству - или вообще к добывающей отрасли? А если программист - не конструктор на самом деле, а, положим, водитель автокара? Почему нет? А что, если результат деятельности программиста - вообще не программа. а нечто другое?
Я озвучил эти идеи на семинаре по Р-технологии в Одессе, в сентябре 1985 года (Праксеологический анализ деятельности программистов). Вообще-то я был заявлен там с докладом "О культуре программирования". Его я тоже прочитал - но это было достаточно рядовым сообщением (хотя мысль о том, что нужно разработчиков не просто учить методологии, но и прививать им определённую культуру - правильная и доселе актуальная: сегодняшним программистам этой культуры не хватает так же, как и тридцать лет назад). Но за время, прошедшее от заявки на семинар до моего там появления (а это было не менее полугода), у меня появилось что сказать ещё.
Поскольку семинаром рулили киевляне, вставить меня вне программы труда не составило - тем более, что, как водится, кто-то заявился, но не приехал. Бенефиса, однако, на этот раз не получилось. Меня весьма жёстко отбрили вальяжного вида москвичи, которых я до той поры не видел - но их фамилии потом встречал в статьях и монографиях, посвященных оценке производительности труда (разумеется, на основе методики Холстеда). Шестой номер УСиМ они уже прочли. И мои нахальные фразы из выступления восприняли конкретно в свой адрес: "Следовательно, вместо изделия мы изучаем инструмент, но называем его изделием, и характеристики инструмента мы используем для оценки количества и качества изделий (приведённый способ измерения производительности труда нелеп ещё и потому, что, фактически, объём работы измеряется после окончания работы тем, кто её делал). "
Отмечу ещё один перл из этого доклада: "Нам могут возразить, что программное изделие и не обязано быть физически существующим, поскольку процесс его создания и использования носит сугубо информационный характер: это переработка информации, а не вещества. Однако, во-первых, любой процесс имеет как физические, так и информационные свойства. Изготовление болта мы можем рассматривать как процесс записи на болванку информации о длине, размере и направлении резьбы. Тот факт, что физическая деятельность при изготовлении болта преобладает, не говорит о его сугубо физических свойствах. "
Понятное дело, я представлял для них угрозу уже тем, что усомнился. Угроза эта - не я сам по себе (кто я такой - малоизвестный тип из Сибири), а тем, что из сильных того мира кто-нибудь мог разыграть эту карту против них. Например, Вельбицкий, который относился ко мне хорошо, а к москвичам - не очень. Как я понимаю, эти две школы конкурировали - не только за идеи, но и за конкретные и очень большие деньги от ВПК. Сам-то я пребывал в блаженном неведении. Я считал, что главное - найти истину и её провозгласить, а дальше уже дело не моё (так же, как в любви когда-то считал главным делом - объясниться).
Вот так, одномоментно, я обрёл не только друзей, но и врагов, и очень серьёзных. Но я тогда этого не понимал, и отнёсся к ситуации легкомысленно: правда всего дороже, и она всё равно найдёт дорогу. Если бы я в отстаивании этой правды был настойчивее, если бы я высунулся сильнее (например, защищал бы по этой теме диссертацию или как-то на этой теме ПРОДВИГАЛСЯ бы - к каким-то ключевым должностям, например), они бы меня сожрали. А так - только грамотно задвинули. Идея, однако, была уже озвучена, она обсуждалась в кулуарах, особенно в группе дальнего заплыва.
Вообще, на семинар съехались не только киевские Р-технологи, но и весьма серьёзные разработчики со всей страны (судя по нежеланию обсуждать их реальные системы - военные). В столовой и, реже, в конференц-зале появлялись какие-то очень важные персоны из Минсредмаша. Как я сейчас понимаю, там большие люди ворочали большими заказами. Кстати, и я был в Одессе не один, а с Сапожниковым. Ему надо было познакомиться с Вельбицким и войти в эту тусовку (нюх на конъюнктуру у него был потрясающий), а я играл роль тарана. Большие люди решали большие проблемы, а заодно и маленькие. Меня там чуть было без меня не женили, отдав в аспиранты Вельбицкому. Сапожников очень удивился, узнав, что я не собираюсь защищаться, при том, что наработок по технологии программирования хватало уже на две диссертации. Но я с тоской думал: опять сдавать математику, да ещё и английский, да ещё и философию марксистско-ленинскую к тому же... (а уже была задумана "Суета сует", где я этот самый марксизм пытался опровергнуть). А потом - я уже повертелся в научных кругах, насмотрелся на то, как всё это готовится и проводится - и "Абсолютно неучёная песня" уже созревала во мне. Вельбицкого моё решение тоже удивило. Но - "у каждого свои недостатки", как говорилось в известном фильме.
Эти же идеи я озвучил на второй всесоюзной конференции по технологию программирования в октябре 1986 года, которую готовили мои друзья-киевляне (О термине "программное изделие"). Программное изделие суть объект, существующий в ЭВМ во время выполнения программы, то есть производство программных изделий происходит на тех ЭВМ, где программу эксплуатируют, а не на тех, где его производят. Мысль о том, что программист тогда - не конструктор, а технолог, оформилась позже, и я её оформил сначала на очередном семинаре Р-технологов (на этот раз на горнолыжном курорте в Карпатах): Об измерении труда программистов, потом в Стендовом докладе на 2 всесоюзной конференции по технологии программирования, потом в материалах краевой конференции (Программирование как деятельность)
Всё это было достаточно революционно по тем временам, и вызвало достаточно большой резонанс (правда, после конференции, а не на ней, потому что мой доклад был стендовым, и люди познакомились с ним уже прочитав сборник тезисов конференции - а на самой конференции к моему стенду подходили разве что мои же знакомые).
Однако я на этом не остановился и посягнул на святое: заявил, что программного изделия нет вообще! (Выступление по материалам тезисов) В окончательном виде моя идея выглядит так:
Я до сих пор считаю, что эта метафора программистской деятельности наиболее адекватна. Что на самом деле происходит? Человечество добывает и перерабатывает информацию. Какие-то участки переработки автоматизируются, какие-то до поры остаются ручными (конкретно - до той поры, пока их не удаётся формализовать настолько, чтобы запрограммировать). Но это единый технологический процесс.
Особенно это видно на бухгалтерских программах. Первые бухгалтерские программы слепо копировали некомпьютерный учёт, вместе со всеми его документами. То есть, бралась имеющаяся технология и как есть перекладывалась в компьютер. Однако выяснилось, что многие операции и документы "бумажного" учёта теперь вовсе не были нужны, потому что они были необходимы для промежуточного контроля ошибок, неизбежных при ручном подсчёте. Тогда разработчики стали смелее - и вместо автоматизации ручного труда предложили вообще другую технологию ведения бухучёта (противоречащую только практике, но не теории бухучёта). Там другие процессы, там другие документы, другие роли бухгалтеров. Технология переработки информации кардинально изменилась, а не просто автоматизировалась.
Когда мы внедряем информационные технологии, мы не просто устанавливаем какие-то изделия, мы меняем (иногда кардинально) саму технологию переработки информации.
Я смотрю сейчас на это определение - ну и что? Трюизм сплошной. Собственно говоря, любой нормальный разработчик или внедренец понимает свою задачу именно так. Однако двадцать пять лет назад это было вовсе не очевидно.
Надо было двигаться дальше - и разрабатывать методики подсчёта производительности труда. Но это было непросто! Мало того, что это было непросто само по себе, но это было катастрофически непросто в той жизненной ситуации, в которой я находился. Это был пик кризиса среднего возраста. Мучительные поиски себя, мучительная любовь, мучительная (уже) ДЕЛЬТА, да вообще полный цугцванг. Какие методики подсчёта, когда ты несколько лет уже боишься выйти на балкон - потому что есть большой соблазн сигануть с шестого этажа?
Чтобы вырваться из заколдованного круга, надо было что-то изменить. Я ушёл из университета (а мог бы уйти из семьи или вообще из жизни). Ушёл как раз под предлогом того, чтобы заниматься исследованиями производительности труда в КФ ВНИИ ПС, хотя никто, кроме себя самого, не мешал мне заниматься этим в университете. И какое-то время, действительно, занимался именно этим, хотя мой начальник отдела, Дмитрий Ильич Дрейцер, имел на меня совсем другие виды. Достаточно быстро он убедил меня, что основная проблема разработки программного обеспечения вовсе не в технологии программирования, а в том, чтобы разработчик понял, что нужно заказчику. Если это не происходит, то можно сколь угодно эффективно делать то, что заказчику на самом деле не нужно. Решение этой проблемы он видел в том, что через какое-то время назовут персональными вычислениями. Напомню, на дворе был 1986 год. Персональными компьютерами в СССР ещё не пахло, да и на Западе они ещё были экзотическими игрушками. Однако в 1987 году в Красноярске был открыт первый в СССР учебный центр по подготовке пользователей персональных компьютеров. Он достоин отдельной главы, и эту главу я напишу ещё.
Что же до философии программирования вообще и производительности труда программистов в частности, то я этим занимался ещё пару-тройку лет, но потом стало сильно не до того. Где-то до середины девяностых я ещё поддерживал связь с киевлянами, которые теперь оказались вообще в другой стране, и даже вёл с ними совместные проекты (например, продавал одну из первых антивирусных программ, разработанную в ИК, а также РБД-МИКРО - реляционную, между прочим, СУБД, работавшую на ДВК - машине, у которой даже винта не было, а было только два флоповода по 200 килобайт, причем одна дискета была полностью занята операционкой). Потом связь оборвалась, да и в Киеве я больше не был. Помню лишь последний семинар в Жуково, в сентябре, кажется, девяностого года. Было очень тепло, мы купались в речке, было много фруктов. Картины кругом были пасторальные - уборка урожая и т.д. Правда, перед отъездом выяснилось, что Жуково находится на границе 30-километровой зоны Чернобыльской АЭС. Когда мы ехали обратно в Киев, эти пасторальные картины рождали совсем другие чувства.
Чуть не забыл рассказать о комиссии по технологии программирования при СЭВ. Как оказалось, в СЭВ (если кто забыл или не знает - Совет Экономической Взаимопомощи, в который входили все соцстраны) существует перечень основных направлений, а при каждом направлении - комиссия. Направления были упорядочены по убыванию важности. Не помню, что стояло на первых четырёх позициях, но на пятом месте была атомная энергетика, а на шестом - технология программирования. Во как! Как я понимаю, это была заслуга именно ИК. Мои киевские друзья постоянно ездили в страны СЭВ (помню, Саша в красках рассказывал о кубинских впечатлениях).
Меня также включили в эту комиссию. Не буду врать, в каком качестве - честно , не помню. Но, видимо, на постоянной основе: на заседания комиссии я ездил регулярно - то в Киев, то в Москву. Приходили мне бумаги на умопомрачительных бланках СЭВ - я был включен в какую-то рассылку. Но и это не помогло мне победить липаевскую команду - потому что для этого провозглашать истину было недостаточно, для этого надо было уметь бороться под ковром, а тут наши силы были неравны, несмотря на то, что киевляне были на моей стороне. А потом СЭВ рухнул вместе с СССР и похоронил все наши разборки.
Забавно, правда, всё это отозвалось спустя много лет, когда мне пришлось снова возглавлять коллектив разработчиков, уже в условиях рынка. Надо было определяться с тем, из чего исходить при определении зарплаты программистов. Поскольку определяющий принцип был "как потопаешь, так и полопаешь", кто-то предложил исходить из длины программы. Ну, тут я, конечно, и выдал! Но, к слову сказать, это было и остаётся основной проблемой: как определить сложность (а значит, и трудоёмкость) предстоящей разработки - а значит, какова будет сумма договора.
Следующая глава будет печальной и в ней будет рассказано о пресловутом КСВ. Её я ещё не написал - ждите примерно через год. А вот, кстати, если вы пропустили главку про группу дальнего заплыва и игру "Клад" - самый раз туда пройти.
Продолжение следует: Скучно в городе Пекине
© Алексей Бабий 1998-2009