ассемблировался бы в текущее состояние запускаемой двоичной программы?
Козелл: Совершенно верно. Одна из проблем состояла в том, что у нас было несколько вариантов текста программы. В одном из них мог быть помечен участок кода, где две строки нужно вычеркнуть, заменив таким-то кодом. Были ли такие пометки во всех вариантах? Хорошо, что Уилл все записывал в свой чудесный блокнот - именно он и был последней инстанцией. Таков был его подход.
Мой же подход состоял в том, что система всегда должна работать сразу. Я не хочу работать с множеством постоянно вносимых исправлений. Придя в проект, я первым делом проделал большую работу, добавив все необходимые заплатки. Мы работали над этим весь день, потом я всю ночь редактировал систему и реассемблировал ее, и утром у нас была готова новая перфолента, с которой можно было работать. После ночной редактуры, как правило, нужно было внести буквально 2-3 изменения, и уже ясно было, каких. Так что сделать это было несложно.
То есть мы почти избавились от такой проблемы, как добавление новых ошибок при исправлении старых, разве что заплатка оказывалась неправильной.
Тут мы с Уиллом здорово спорили, потому что он действительно любил ставить заплатки, стремясь держаться подальше от ассемблера, - отчасти потому, что это занимало много времени, а так он мог, поставив заплатку, работать дальше, а отчасти потому, что не доверял циклу, считая редактирование слишком опасным.
Сейбел: Считаете ли вы работу над IMP одним из своих главных профессиональных достижений?
Козелл: Как ни странно, нет. Да, это был интересный, трудный проект. Но кроме него я написал DOCTOR, программировал на Лиспе, стал “царем больничной компьютерной системы”. По- настоящему важной для меня работой была работа над той революционной системой разделения времени, в которой я так тщательно разобрался. A IMP был просто одним небольшим коммуникационным процессором. Там не было столько каналов прерываний, как на PDP-1. Не приходилось решать проблемы вроде такой: как быть, если у тебя всего 32 слота для своппинга, а в системе авторизовано 40 человек?
Работа с IMP принесла нам известность, это было весело и интересно. Написать и отладить некоторые места было действительно непросто. Но я бы не назвал это вершиной своей карьеры. Это была просто еще одна программа. К тому же система IMP была весьма ограниченна в применении. Работа же PDP-1 была настоящим вызовом. Это была система разделения времени, которую требовалось постоянно развивать.
Самое примечательное в системе IMP - это скорость, с которой мы ее сделали. Ребята официально начали работать над ней в январе, я присоединился в феврале, а в сентябре она была уже готова. Относительно “готова”, потому что мы продолжали вылавливать баги и вносить еще некоторые изменения. Но все же в сентябре программа официально была выпущена. Вскоре Уилл перешел в другой проект, а мы с Дэйвом и еще пара новых ребят продолжили дорабатывать систему.
Должен выразить самую искреннюю благодарность Фрэнку Харту. Не знаю, как ему удавалось руководить нами, при этом всегда позволяя оставаться самими собой. Не припоминаю ни одного собрания программистов. Не припоминаю, чтобы нас хоть раз загрузили бумажной работой, когда наши головы были полностью заняты программой и некогда было отвлекаться на все это. Это был такой уровень доверия и уверенности, когда нам троим просто дали эту работу и оставили в покое. Оглядываясь назад, я понимаю теперь, как это трудно быть менеджером проекта и какую потрясающую работу проделал Фрэнк. Никаких еженедельных собраний сотрудников, никакого рисования PERT-диаграмм на доске. Уилл, конечно, отслеживал текущие задачи, найденные ошибки и прочую проделанную работу, но отсутствие какого-либо систематического надзора над нами поражало. Собрать нас вместе, дать нам поручение и уйти в тень - думаю, для руководителя это был очень смелый поступок.
Другой прием, которым пользовался Фрэнк, - ревизии проекта. Тогда мне казалось, что у него они самые серьезные из всех возможных, и со временем мое впечатление не изменилось. У него на ревизии сотрудники тряслись от страха. Это было нечто вроде защиты диссертации. Он собирал в аудитории несколько человек, и ты должен был представлять свой проект. Тебя слушали со всей доброжелательностью, но при этом Фрэнк всегда сразу понимал, в каком месте ты блефуешь.
Думаю, каждый, кто прошел такую ревизию, знает: если ты проработал некоторые части недостаточно хорошо, то во время доклада стараешься побыстрее их проскочить. Тебе кажется, что все в порядке, но на самом деле ты недостаточно все проанализировал и в целом не очень понимаешь, что происходит. У Фрэнка на такие вещи был настоящий нюх, подкрепляемый подбором нужных людей, так что ему без труда удавалось засечь блеф и поймать тебя как раз на том, что ты недостаточно продумал.
Та часть выступления, в которой ты был уверен, не вызывала интереса. Тебе просто говорили: “О!” Но на той части, где ты “плавал”, непременно концентрировали внимание. Я знаю тех, кто действительно боялся таких ревизий. Неуверенный в себе программист мог подумать, что его раскритиковали, выставив некомпетентным, и все плохо.
На самом же деле все было не так, и с другой стороны стола это было отлично видно. Ревизия проекта помогала сотруднику двигаться в верном направлении при работе над проектом. Там, где он чувствовал себя уверенно, он мог разобраться и сам. Но зато лучшие умы BBN могли подсказать ему что-то в тех местах, которые он недостаточно продумал. Почему так получилось? О чем он вообще думал? Что пошло не так? За 15 минут можно было получить реальную помощь.
Нужно быть достаточно уверенным в своих навыках профессионалом, чтобы сказать: “Отлично. Вот моя проблема. Я не знаю, что с ней делать, и когда готовил свой отчет, надеялся, что вы, ребята, этого не заметите и одобрите его”. Естественным ответом на это будет: “Конечно, мы одобрим его, потому что он выглядит хорошо. Теперь давай разберемся с твоей проблемой - наши лучшие парни собрались здесь как раз для того, чтобы ты не бился над этим сам еще неделю или две”.
На самом деле подобные ревизии нужны самому сотруднику, помогая ему убедиться в правильности решений в случаях, когда он знал, как это сделать, или получить совет там, где он сам понимает свою слабость. Когда я понял это — в мои 20 лет или, возможно, годом позже, — мне стало очевидно, что такая помощь старших товарищей чрезвычайно полезна.
Конечно, для клиента составлялся другой отчет, весь в радужных тонах. Но для сотрудника такие внутренние отчеты были реальной возможностью вырасти профессионально. И меня всегда удивляло, насколько многие люди их боятся. Умный парень может уверять себя и других в том, что его отчет будет порван на клочки. Хотя ясно, что не будет, если в нем есть хоть что-то хорошее, и что тут собрались не его враги. Но убеждать в этом такого парня было совершенно бесполезно. Он все равно пытался пустить всей BBN пыль в глаза, рассказывая о том, как все замечательно.
Не менее трудно было объяснить ему, что в другой раз столько хороших специалистов не соберутся вместе только для того, чтобы помочь ему справиться с его проблемой. После этого придется справляться уже самому, и это замечательный опыт.
Сейбел: Как часто проводились подобные ревизии? Один раз в самом начале проекта или периодически на протяжении всего срока работы над ним?
Козелл: Многократных ревизий не было. Обычно она проводилась один раз сразу после того, как ты разработал проект.
Сейбел: Получается, нужно было знать, как будет выглядеть результат, еще до того, как начнешь программировать?
Козелл: Да, точно. Именно так. Наверное, что-нибудь запрограммировать все-таки придется, потому что многим, включая меня, требуется собрать по кусочку кода, чтобы понять, как все в итоге будет работать.
Но обычно мы работаем в жестко заданном цикле: сначала предлагаем какой-то программный продукт, потом делаем его. То есть мы должны показать клиенту, что собираемся сделать, и показать хорошо, потому что после этого он даст нам деньги и время на работу и должен знать, за что он платит. Итак, на этом этапе мы определяемся с требованиями и пишем себе техническое задание. После этого разбираем его внутри компании, чтобы удостовериться, что нам все понятно. Не помню, чтобы Фрэнк вмешивался в уже начатые проекты. Во всех проектах, где я работал, Фрэнк не интересовался промежуточными результатами работы.
