Вооружившись словом
Техническая терминология и обычная речь зачастую тесно взаимодействуют друг с другом. В компьютерный лексикон вошло много повседневных слов в качестве строгих технических терминов. Такие слова, как "объект" или "сущность", заимствованы для обозначения понятий, которые никак не связаны с окружающим нас физическим миром. Мы присвоили "метод" и "сообщение", "протокол" и "папку" (file). Конечно, происходит и обратный процесс. Технические термины входят в обиходную речь в такой степени, что компьютерный жаргон теперь можно услышать даже в разговорах на улице.
Специалисты по компьютерам особенно любят переносить свой жаргон в обычный разговор, расширяя значение терминов таким образом, чтобы их можно было применять при общении. Они стараются произвести "пар-синг" (parsing) неразборчивого сообщения на автоответчике или маниакально "мультиплицируют" два разговора. Привычные поведенческие шаблоны таких специалистов "жестко запрограммированы в ПЗУ". Программисты "портируют" автомагнитолу с одной машины на другую, а не покупают новую деку. Для того чтобы написать черновик отчета о вчерашнем совещании, они осуществляют "дамп оперативной памяти". Все это может стать весьма утомительным и звучать ужасно глупо, однако порой техноболтовня обогащает обычный язык полезными и интересными новшествами.
Я помню свой первый опыт применения программной терминологии в устной речи. Наша группа занималась экспериментами, связанными с коммерческим использованием языка Lisp. Мы настолько увлеклись этим языком, что стали говорить списками и точечными парами. В на-ших разговорах то и дело встречались довольно своеобразные высказывания. Мы "cons" две идеи вместе, а также "саг" и "cdr" темы разговора. Такая беседа могла быть настолько "многопоточной", что в конце концов кто-нибудь жаловался на "переполнение стека" и просил о сборе мусора. Для тех, кто никогда не учился "шепелявить на ЛИШПе" (thpeak with а lithp), скажу, что "саг" означает "первый элемент списка", или "левая часть", а под "cdr" (произносится "куд-эр") понимается "остальная часть списка", или "правая часть". Такие странные названия закрепились в Lisp несмотря на то, что они относятся к аппаратным регистрам давно исчезнувшей IBM 709/7090/7094 и буквально означают "содержимое адресного регистра" и "содержимое регистра декремента".
Наша вычурность продолжалась недолго. Вероятно, она казалась глупой и не была особенно полезной. Ну, разве что помогла нам изучить жаргон и лучше запомнить понятия языка Lisp. Уже много лет я не "cadadr"'jo какую-нибудь идею. Хотя если сегодня побродить по нашим офисам, то можно услышать не менее странные, а порой и более полезные идиоматические выражения.
Офисный протокол
Обычные способы прервать кого-либо, принятые в приличном обществе, могут быть слишком медленными и неудобными для эффективного взаимодействия. "Извините, вы не заняты? Надеюсь, не помешаю. У меня только один небольшой вопрос, на одну секунду." На одну секунду? Это уже заняло 6,5 секунд! К этому моменту прерывание сталоfait accompli.К тому времени как ваш мозг разобрался и обработал весь этот шум и принял решение о том, что с этим делать, вы уже забыли, на какую строку кода смотрели и какой метод какого подкласса собирались задействовать.
Для рабочих групп нужен словарь прерываний, который был бы кратким, приятным и простым. То, что подходит для аппаратного обеспечения, подойдет и для людей, поэтому в наших офисах мы тоже IRQ, АСК и NAK.
IRQ - это сокращение от "interrupt request" (запрос прерывания, произносится "ирк"). Например, "Можномне "ирк" вас?". Впрочем, достаточной одного слова "Ирк?". Восходящая интонация делает высказывание более вежливым, а взрывной согласный звук в конце слова привносит оттенок настойчивости. Это слово звучит достаточно отчетливо, чтобы его можно было услышать среди шума вентиляторов и визга лазерных принтеров. В то же время, оно достаточно коротко, чтобы не сильно отвлекать от ментальных процессов. Возможные ответы: АСК и NAK (первое произносится "эк", второе - "эн-эк" или "нэк"), что означает "Ок, давайте!" и "Нет, не сейчас!" соответственно. Не нужно отрываться от ваших дел, чтобы пробурчать либо "эк", либо "нэк". Оба варианта ответа имеют характерное фонетическое звучание, что делает их различимыми при прерывании.
Протокол прерываний чрезвычайно прост. Тот, кто хочет прервать кого-нибудь, говорит "Ирк!" и ждет ответа. Тот, кого прерывают, может еще некоторое время продолжать свою работу, пока не подтверждено установление связи. Например, он может пометить место в тексте, заполнить поле заголовка или оставить себе короткую записку-напоминание. Когда сотрудник готов обслужить прерывание, он отвечает: "Эк". Ответ "Нэк" означает: "Нет, не отвлекайте меня сейчас". Это можно расценить как вежливый вариант высказывания "Уйди отсюда и не стой над душой". Все эти слова кажутся очень глупыми, но такая простая система может поразительным образом способствовать более гладкому взаимодействию в рабочей группе. Иногда в словарь может входить высказывание NMI (произносится "ними"), что означает "немаскируемое прерывание". По правилам этикета такое высказывание должно применяться лишь в критических случаях, требующих наибольшего приоритета обработки со стороны центральной нервной системы вашего бедного коллеги. Прежде чем начать говорить, лучше сделать короткую паузу, хотя дожидаться АСК или NAK не требуется.
Людей, которые слишком часто применяют IRQ, называют надоедливыми.. С ними можно поступать на манер кота Билла, громко крича "Эк, нэк. Нэк! Эк!" и вырывая на себе волосы. Если в нужный момент вы сможете превратиться в пушистый клубок, то это будет еще более эффективно.
Конец прерывания.
Из журнала Software Development, том 2, № 6, июнь 1994 г.
II
Ковбои и ковгерлы
7
Кодеры-ковбои
Наступило новое тысячелетие, а вы даже не знаете об этом! Программное обеспечение наконец-то стало надежным. Как же был достигнут этот прорыв в области проектирования программного обеспечения? Вот цитата из 16-страничного рекламного буклета корпорации Nanomush Inc., который был разослан миллионам отсталых пользователей и разработчиков: "Одним из самых мощных дополнений к Blerbbleflox 3.1 является "проверка параметров" (parameter validation). Когда информация поступает из какого-либо приложения в операционную систему Blerbbleflox, система проверяет правильность полученных данных". Вот такая новая идея! Почему же вы об этом не думали, а? (Естественно, все поняли, что речь идет о Microsoft и Windows 3.1.)
Эта попытка самовосхваления открыла, что корпорация Nanomush, являющаяся одним из мировых лидеров в области разработки языков и операционных сред, в конечном счете стала применять самые элементарные приемы надежного проектирования программного обеспечения. Это настолько основополагающие приемы, что каждый человек, достойный имени программиста, знает и применяет их вскоре после того, как приобретает способность кодировать. Может ли это пролить хоть какой-то свет на недостатки в предыдущих версиях программного обеспечения? Однако нужно не придираться, а радоваться и хвалить всех начинающих разработчиков программного обеспечения за их усилия, а также поощрять их стремление к дальнейшему профессиональному развитию. Возможно, таким специалистам следует посоветовать книги о связывании и сцеплении или о том, как скрывать информацию от пользователя.
О том, почему компьютерный мир пришел к такому плачевному состоянию дел в области системного программного обеспечения, можно говорить долго. Но лучше пристальнее взглянуть на характер разработчиков, создавших некоторые из тех продуктов, от которых мы так сильно зависим. Мои коллеги, занимающиеся организационной динамикой, иногда называют их "ковбоями". Ковбоев, этих последних из грубых и диких индивидуалистов, можно встретить в разных местах, но в настоящее время многие из них пасут коров на силиконовых полях, причем эти коровы говорят на ассемблере. Кстати, обратите внимание на то, что прозвище "ковбои" заканчивается словом "мальчики" (boys), а не "мужчины" (men).
Весной 1992 года я участвовал в конференции по разработке программного обеспечения (Software Development Conference), организованной компанией Miller Freeman. Один из семинаров был посвящен такой скользкой теме, как "структурированное" и "неструктурированное" управление процессом разработки программного обеспечения. Я сидел рядом с одним из представителей компании Nanomush, отвечающим за разработки. Он был всецело на стороне ковбоев. Его позиция заключалась в том, что полному раскрытию потенциала разработчиков препятствуют руководители, которые стремятся ввести стандарты, ограничения или во всеуслышание заявляют об ожидаемых результатах. По его мнению, нужно просто отойти в сторону и не мешать программистам делать свое дело. Структурированные методы, регламентированная разработка, моделирование на бумаге и оценка программного обеспечения - все это неоправданно ограничивает возможности свободного творческого самовыражения наших блестящих ковбоев-программистов. Неудивительно, что продукты, поставляемые такими компаниями, так непредсказуемы в работе.
Почему нужно выпустить четыре релиза и задействовать 12000 сайтов бета-тестинга (это не шутка!) для того, чтобы выражение "необратимая ошибка в работе приложения, ок?" заменить на более понятное? Но ковбои не любят, когда их обуздывают с помощью особых критериев качества. Ковбоям не нравится заранее думать о том, какие функции продукта действительно необходимы. Нет, давайте лучше просто заскочим в старый добрый загон для разработки и настрочим какой-нибудь код - мы ковбои! Можно придумать симпатичный графический интерфейс и применить искусные методы кодирования - как-никак мы творческие ж гениальные личности. Но к черту юзабилити и надежность - для этого может потребоваться планирование или дисциплина (боже упаси).
Не стоит выделять какую-либо из компаний, разрабатывающих программное обеспечение. На рынке имеется бесчисленное множество примеров, подходящих для иллюстрации. Тем не менее очень редко в соответствующей литературе или на семинарах специалистов можно ветре-тить беспристрастную оценку зрелости разработчиков и качества методов программирования.
Зрелость индивидуалистов
Зрелость является центральным вопросом в разработке программного обеспечения. Методисты хотят знать, сколько времени должно пройти для того, чтобы проектирование программного обеспечения созрело как дисциплина. Менеджеры беспокоятся об уровне "зрелости процесса" в тех подходах к разработке, которые применяются в их организациях. Наконец, руководителей проектов интересует зрелость тех индивидуумов, руководить которыми их пригласили.
Одна большая корпорация провела исследования в своих группах, разрабатывающих программное обеспечение. Исследовалось, как часто и на каком уровне сложности эти группы применяют общепринятые систематические или строгие подходы к проектированию программного обеспечения. Оказалось, что наиболее эффективно методы проектирования использовались отделом администрирования информационных систем и отделом деловой информации. Средние результаты показали группы обеспечения проектирования. Как вы догадались, группы, разрабатывающие операционные системы, компиляторы и сервисное программное обеспечение, замыкали таблицу. Исследования о распространенности инструментов CASE дают ту же картину. Там, где дисциплине в проектировании и зрелости процесса не придается значения, разработка программного обеспечения напоминает шоу о Диком Западе, в котором главные роли играют кодирующие ковбои.
Наша культура превозносит гения-одиночку, который от начала и до конца разрабатывает какую-нибудь блестящую теорию, машину или программу. Однако на самом деле никто не делает это, полагаясь только на свои силы. Даже хакер-подросток, укрывшийся в своей спальне и взламывающий программу с помощью собранной им же самим машины, зависит от целой армии инженеров, которые спроектировали и создали чипы, и от целых легионов программистов, которые создали соответствующие инструменты. Для тех, кто следит за моим "показателем скрытой половой дискриминации" (LSI, Latent Sexism Index), скажу, что здесь я не случайно использую местоимение мужского рода. Большинство юных хакеров - мужского пола, а особый склад ума, связанный с желанием взламывать онлайновые компьютерные системы или запускать новых изощренных червей для того, чтобы полностью нарушить работу сетей, почти исключительно является предметом мужской психопатологии. Большинство актов вандализма также совершается подростками, и давайте признаем это. Сочинение вирусов, уничтожение файлов компаний или взламывание правительственных компьютеров является просто-напрос-то вандализмом и ничем иным. К сожалению, не за горами то время, когда такой компьютерный вандализм начнет приводить к потерям в людях, тем более, что уже несколько раз мы были близки к этому.
Совместное обучение
Итак, как же мы всего за несколько абзацев перешли от проектирования программного обеспечения и методологической зрелости к вопросам, связанным с полом? Суть состоит в том, что незрелое ковбойское мышление, отвергающее как дисциплину, так и сотрудничество, в значительной степени свойственно мужчинам.
На одной встрече группы планирования, проходящей в компании по разработке программного обеспечения, у собравшейся "команды" ушло 40 минут на конкурентные игры мужчин. Они спорили по поводу определений, старались занять выигрышную позицию, рисовались своими знаниями и эрудицией. В целом, каждый старался одержать верх над другими. Постепенно, один за другим, эти мужчины уходили с совещания под тем или иным предлогом. Чаще всего это было нечто "более важное", имеющее отношение к "реальной работе". Когда же остались только женщины, одна из них сказала: "Ну вот, сейчас мы можем что-то сделать". Они быстро и эффективно справились с задачей, получая удовольствие от самого процесса общения.
Конечно, это стереотип, но нам, парни, нужно признать, что женщины лучше понимают, что такое сотрудничество. Какие бы причины ни лежали в основе этого, маленькие мальчики стремятся состязаться, а маленькие девочки стремятся сотрудничать. Женщинам, как правило, намного лучше удается выстраивать отношения, поддерживать и поощрять друг друга. (Можно спросить, почему же в нашей отрасли они так редко бывают менеджерами и руководителями проектов. Задумайтесь об этом, руководители среднего и высшего ранга: при прочих равных условиях женщина может иметь явное преимущество над мужчиной в качестве лидера команды, даже если команда состоит из тех программистов-неандертальцев, которые утверждают, что не могут работать на женщину.)
В те годы, когда я был семейным терапевтом, я с неохотой пришел к выводу, что большинство современных мужчин знает очень мало о том, что такое воспитание детей или семейные отношения в целом. Это сказано не для того, чтобы принизить мужской пол, это всего лишь статистический факт. Мне посчастливилось встретить необыкновенных мужчин, которые хорошо разбирались в том, как устанавливать отношения. Также я встречал женщин, не способных к общению. Ни тот, ни другой пол не удерживает монополию ни на чувствительность, ни на способность уста-навливать отношения. Но говоря об умении ладить с людьми, нужно отметить, что по крайней мере в большинстве культур у женщин есть преимущество.
Думаю, сейчас я услышу, как кодирующие ковбои станут долго и настойчиво уверять в том, что суровый индивидуализм и независимость в сфере программирования есть единственная надежда американского бизнеса (или человечества - в зависимости от наивности мировоззрения). Именно они утверждают, что совместная работа ограничивает их в средствах, что приход к согласию низводит их до уровня наименьшего общего знаменателя, что необходимость проектировать до начала кодирования затормаживает их работу. Странно, что многие из них создают такие посредственные программы или даже системы, наделенные существенными недостатками.
По правде говоря, встречаются отдельные люди, как мужчины, так и женщины, которые настолько одарены, дальновидны, талантливы и способны к творчеству, что могут выполнять работу самостоятельно и создавать надежные, достойные похвалы продукты. Однако для большинства из нас возможность проявления нашего потенциала основана на умении соединять идеи каждого в творческом синтезе, когда результат превосходит то, что каждый из нас мог бы сделать в одиночку. Наша работа, скорее всего, будет лучше, чем моя работа либо ваша.
Поэтому растите, ковбои! Учитесь, как становиться на плечи друг друга, а не наступать на ноги. И пусть нам подадут руку помощи женщины, ведь нам нужно так многому научиться.
Из журнала Computer Language Magazine, том 9, № 8, август 1992 г.
8
Возвращение блудного ковбоя
Когда я впервые обратился к теме программного обеспечения, чтобы написать о проблеме "кодеров-ковбоев", я даже не представлял себе, какое осиное гнездо потревожу. Кодеры-ковбои - это как раз те обитатели индустрии, которые чернят дисциплину любого рода и с равным презрением отвергают методы, модели и менеджмент. Они скорее уйдут, чем станут сотрудничать. Мысль о необходимости проектирования до начала кодирования вполне может привести их к настоящей клаустрофобии. Моя идея о том, что эти ковбои (в основном, мужчины) могли бы поучиться сотрудничеству у коллег женского пола, вызвала целую бурю протестов. Почти все протестующие были мужчинами. Они обвиняли меня во всем, начиная от дискриминации по половому признаку и заканчивая коммунизмом, поэтому неудивительно, что некоторое время я воздерживался от возврата к этой теме. Но обстоятельства, похоже, вынуждают меня вновь поразмышлять о диких местах в дебрях программирования.