Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса - Кен Косиенда Страница 15

Обустройство не заняло у Ричарда много времени. Через два дня он позвал нас к себе посмотреть демоверсию. Что?! Демоверсию?

Мы с Доном пришли в темный кабинет Уильямсона, где не было окон и светился только экран его компьютера Mac. Мы заглядывали к нему через плечо, пока Ричард щелчком мыши запускал веб-браузер. Не просто оболочку, а настоящий, действующий браузер. Он успешно загружал страницы, «кликал» ссылки, возвращался назад, «кликал» другие ссылки, загружал еще страницы — в целом, он серфил по интернету как ни в чем не бывало. Что же, черт возьми, мы видели?

Уильямсон объяснил, что перед нами Konqueror, один из браузеров с открытым исходным кодом, о котором мы рассказали ему пару дней назад. Konqueror был разработан в проекте KDE — сообществе программистов, чьи цели были схожи с проектом GNOME. KDE также представлял собой полнофункциональную компьютерную среду, похожую на Mac и Windows, систему, построенную вокруг свободного программного ядра Linux.

Ричард рассказал, что он загрузил KDE и поставил себе простую цель: добиться работающего на Mac кода так быстро, как только возможно, чтобы он мог оценить потенциал веб-браузера Konqueror. Поскольку KDE работает на Linux, а не на Mac OS X, Ричарду пришлось, как он сказал, сделать оболочку — дополнительное программное обеспечение, которое заставляло Konqueror «думать», что он работает на компьютере с Linux, а потом «убеждало» компьютер, что браузер — это программа, сделанная под Macintosh. Внесу ясность: написать оболочку чрезвычайно сложно. Понимать, что эта проблема разрешима, было потрясно. Всего за два дня у нас была рабочая оболочка, так что уверенность Ричарда в своих силах оказалась небезосновательной. Да что там, это был высший пилотаж программирования.

Видя наше изумление, Уильямсон сказал нам, что были две хитрости, с помощью которых он заставил свою демоверсию работать. Во-первых, он использовал графическую подсистему Linux X Windows вместо графической системы Apple, оригинальной для Mac OS X. Во-вторых, он запустил всю систему KDE, а не только веб-браузер Konqueror. Если для вас эти слова могут звучать как техническая абракадабра, то для нас они ею не были. Чем дальше Ричард описывал свою работу, тем больше мы с Доном понимали, как эти хитрости позволили ему быстро воспользоваться кодом Konqueror.

Уильямсон не беспокоился о том, что X Windows не идеально встроилась в горизонтальное меню вверху экрана Mac, о том, чтобы шрифты отображались один в один, строго до пикселя, о том, что система KDE включала множество программного обеспечения, не имеющего отношения к веб-браузеру. Ричард знал, что эти технические детали придется решать в процессе разработки, но также он знал, что тревога по поводу хитростей, которые он применил, исчезнет из сознания смотрящих демоверсию, как только он повернется к компьютеру и нырнет в интернет с помощью чего-то, выглядящего очень похоже на браузер для Macintosh.

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

Мы с Доном шесть недель работали над созданием веб-браузера для Macintosh, но у нас все еще не было работающего кода и никаких вариантов его сделать. За очень маленький отрезок этого времени Ричард загрузил веб-браузер из Linux и приспособил Konqueror так, что его можно было загружать на Mac. Его демоверсия браузера работала, она могла загружать веб-страницы, она не «падала» и хорошо себя показывала. Мы с Доном были восхищены. Если бы Ричард еще и повторил свои движения коленчатого вала, думаю, я бы упал в обморок.

Как же Уильямсон всего этого добился? Мы с Доном были опытными программистами, и Дон многие годы занимался разработкой браузеров в Netscape, тем не менее демоверсия Ричарда сразила нас наповал.

Можно ли лучше оценить его достижение, измерить его качественно и количественно? Возникает искушение процитировать легендарное высказывание и назвать Ричарда «10х программистом» — суперпродуктивным гением, который может приносить намного больше пользы, чем простые смертные{9}.

Существуют ли такие люди в действительности? Пожалуй, такие скачки между посредственностью и гениальностью не слишком часто встречаются в повседневной жизни. Человек, сидящий за соседним столиком в кофейне, не сможет набирать пятьсот слов в минуту на клавиатуре своего ноутбука, тогда как вы на своем печатаете едва ли пятьдесят. Мир физических законов устанавливает строгие ограничения. Это утверждение остается верным, даже когда речь идет о людях, добившихся высочайших результатов в своей области. Ни один олимпийский чемпион не сможет пробежать стометровку менее чем за секунду.

Имеют ли эти ограничения отношение к развитию информационных технологий? В классической книге по разработке программного обеспечения «Мифический человеко-месяц»{10}, вышедшей в 1975 году, Фредерик Брукс говорит, что имеют. Рассказывая о том, чему он научился, будучи руководителем проекта по созданию операционной системы мейнфреймов OS/360 в 1960-е годы в IBM, Брукс делится наблюдением: «Если задачу нельзя разбить на части, поскольку существуют ограничения на последовательность выполнения этапов, то увеличение затрат не оказывает влияния на график. Чтобы родить ребенка, требуется девять месяцев, независимо от того, сколько женщин привлечено к решению данной задачи»{11}.

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

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

Более того, Ричард за два рабочих человеко-дня сделал для нашего проекта больше, чем мы с Доном сделали за предыдущие