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

Видеть с высокой степенью разрешения вы можете только в относительно небольшой области, и даже там, в самом ее центре, есть крупное пятно, в котором видимости нет, и несмотря на это, вы полагаете, что у вас панорамное зрение со сверхвысоким разрешением. Почему? Потому что ваши глаза очень быстро двигаются, и в обычной ситуации они мгновенно перенаправляются туда, куда вам требуется. А ваш мозг поддерживает это совершенно абстрактное представление, создавая иллюзию полного обзора, тогда как на самом деле вы располагаете очень маленькой областью острого зрения, обширной областью очень слабого зрения и способностью загружать отсутствующую страницу памяти для всего, что хотите видеть, — так быстро, что можно не сомневаться: этот маленький театр в вашем мозгу показывает всю картину.

Это чрезвычайно полезная схема, применяемая и во многих других ситуациях. Ваш слух способен улавливать важные части разговора. Ваши пальцы шарят повсюду и ощупывают все, что нужно, — шерстяной свитер или внутренность носа, — давая полную картину ощущений. Во время сна ваш мозг задает органам чувств те же вопросы, что и наяву (взгляни-ка, что там?!), но органы чувств временно отключены (вы же спите, в конце концов), и мозг, подставляя ответы как попало, сплетает причудливые рассказы, называемые снами. Аутром, пытаясь пересказать приятелю свой сон, несмотря на кажущееся ощущение абсолютной реальности происходившего, вы вдруг обнаруживаете, что на самом деле ничего не помните, и сочиняете что-то на ходу. За следующую минуту-другую сна ваш мозг успел бы спросить у органов чувств, что это за млекопитающее плавает вместе с вами в розовом кусте, и получить любой дурацкий ответ (утконос!), но вы проснулись — и даже не осознавали отсутствие потребности определить, что было рядом с вами в розовом кусте, до попытки связно передать свой сон приятелю. Что у вас никогда не получится. Так что прошу не рассказывать мне свои сны.

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

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

Допустим, к примеру, что эта ваша мечта состоит в том, чтобы переделать старую программу-ежедневник для DOS, очень-очень хорошую, но совершенно недооцененную. Кажется, что это несложно. Ее работа выглядит настолько очевидной, что вы даже не пытаетесь проектировать новый продукт, а просто набираете команду программистов, которые тут же начинают выдавать код.

При этом вы сделали две ошибки.

Во-первых, вы попали в ту самую старую ловушку, когда ваш мозг переоценивает свои силы. «Да у нас нет никаких сомнений в том, как это сделать! Все абсолютно ясно. Не нужно писать спецификацию. Сразу пишем код».

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

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

Что меня убивает, так это дурная привычка некоторых команд собирать совещание, чтобы выяснить, как должна работать какая-то функция. Вы не пробовали коллективно сочинять стихи? Представьте банду тупых каменщиков, которые, сидя на диване, пытаются одновременно смотреть «Спасателей Малибу» и писать оперу. Чем больше тупых каменщиков на диване, тем меньше шансов, что у них получится опера.

Хоть телевизор-то выключите!

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

У Chandler нет даже талисмана!

Повторяю, я не берусь утверждать, с какими неприятностями они столкнулись. Может быть, ни с какими. Может быть, они считают, что все идет по плану. Отличная книга Скотта Розенберга (Scott Rosenberg), предполагаемая «Soul of a New Machine» («Душа новой машины») самого замечательного open source-проекта десятилетия, заканчивается на печальной ноте. Скотт оборвал повествование, потому что было ясно — ждать скорого выпуска Chandler 1.0 не приходится (может быть, Розенберг опасался, что ко времени выхода программы книг вообще уже не будет, а все знания мы станем получать, глотая таблетки).

Тем не менее, это замечательный обзор одного из конкретных типов программных проектов — тех, которые непрерывно движутся, но никуда не прибывают, потому что замыслы были слишком величественны, а деталей немного не хватало. Насколько я могу судить, первоначальное видение Chandler в значительной мере ограничивалось тем, что продукт должен быть «революционным». Не знаю, как вы, но я не умею писать «революционный» код. Чтобы написать код, мне нужны кое-какие подробности. Если в спецификации продукт описывается с помощью эпитетов («должно быть суперкруто»), а не конкретных характеристик («панели заголовков должны быть в стиле необработанного алюминия, а у значков должно быть легкое отражение, как будто они стоят на крышке рояля»), готовьтесь к неприятностям.

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

«Одноранговость» была raison d’etre 11 для Chandler — стоит ли покупать Microsoft Exchange Server чтобы координировать графики? Выяснилось, что одноранговая синхронизация слишком сложна или связана с какими-то проблемами, поэтому данную функцию убрали. Появился сервер под именем Cosmo.

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

Размышляя над этой идей, приходишь к выводу, что она неудачна. Размещать электронную почту в календаре? Где? В день получения? Чтобы в результате я, получив в пятницу 200 писем с рекламой виагры, не заметил важную встречу — собрание акционеров?

В результате «совместное хранение данных» было переработано в идею марок, чтобы, например, можно было «наклеить почтовую марку» на любой документ, заметку или календарное событие и послать их всем, кому нужно. Сообщаю: такая функция существовала в Microsoft Office лет десять. Из Office 2007 ее наконец-то изъяли, потому что она была никому не нужна. И без того есть масса простых способов отправить что-то по почте.

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

Еще Митчел Капор (Mitchell Kapor) охотно рассказывал всем желающим, что Agenda позволит ввести текст вроде «следующий вторник», а после этого волшебным образом назначить встречу на следующий вторник. Это потрясающе, но любая из приличных программ, написанных за последние десять лет, умеет делать то же самое. Ничего революционного здесь нет.

Команда Chandler также переоценила объем помощи, получаемой от добровольцев. Open source действует не совсем так. Этот метод хорош для реализации «содранных» функций, потому что в этом случае есть спецификация — приложение, которое вы копируете. Он очень хорош для функций, которые не терпится реализовать. Мне нужен аргумент командной строки для EBCDIC, так я добавлю его в код и опубликую. Но если приложение ничего пока не делает, оно никому не интересно. Никто им не пользуется. И добровольцев не будет. Почти все разработчики Chandler получают зарплату.

Еще раз приношу глубокие извинения команде Chandler, если Розенберг чего-то не понял или совершенно неверно представил причины задержки, но я и не скрываю, что склонен объяснять такого рода катастрофы ошибками проектирования.

При всем сказанном, такой проект порождает одну хорошую вещь -восхитительную книгу в духе «Души новой машины» и «Шоустоппера» («Showstopper»), рассказывающую о программном проекте, который не удалось довести до конца. Весьма рекомендую.

11 Смысл существования, разумное основание (фр.). — Прим. перев.