В марте 2000 года я запустил сайт «Joel on Software», сделав при этом сомнительное утверждение «большинство людей ошибается, полагая, что для создания успешной софтверной компании нужна уникальная идея» (www.joelonsqftware.ccm/articles/fog0000000074html):

Последние пять лет я проверяю эту теорию на практике. Формула компании, которую мы с Майклом Прайором (Michael Pryor) создали в сентябре 2000 года, включает четыре элемента:

Это довольно удобная формула. Особенно с учетом того, что нашей истинной целью при создании Fog Creek было создать такую компанию, в которой мы и сами хотели бы работать. Тогда я утверждал, что лучшие

условия труда (или «создание такой софтверной компании, где захотят работать лучшие в мире программисты») ведут к прибыли так же естественно, как шоколад — к лишнему весу, а мультяшный секс в видеоиграх — к гангстерской стрельбе.

Сегодня я хочу обсудить только один вопрос, потому что если ответ на него не верен, то и вся моя теория распадается. Так вот, вопрос: есть ли вообще смысл сотрудничать с «лучшими программистами»? Неужели разница между программистами столь велика, что имеет значение?

Для нас с вами ответ может быть очевиден, однако многим другим требуется доказательство.

Несколько лет назад некая крупная компания хотела приобрести Fog Creek. Я знал, что этому не бывать, поскольку слышал, что директор этой компании заявил, что не разделяет мои взгляды насчет работы с лучшими специалистами, ссылаясь на библию: мол, нужен один царь Давид и армия солдат, умеющих выполнять приказы. Акции его компании упали с 20 до 5 долларов, и хорошо, что мы тогда отказались от его предложения, правда, вряд ли во всем виноват культ царя Давида.

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

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

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

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

По существу, разработка программного продукта увеличивает его ценность быстрее, чем затраты на его производство.

Грубо говоря, урезав расходы на программистов, вы выпустите дрянной продукт, но при этом мало сэкономите.

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

Или, другими словами, есть смысл пригласить Анджелину Джоли сняться в вашем блокбастере, несмотря на то что она затребует весьма высокий гонорар, потому что ее гонорар можно разделить на миллионы зрителей, которые пойдут на этот фильм только потому, что Анджелина так хороша.

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

Начнем со старого вопроса продуктивности. Измерить продуктивность работы программиста достаточно сложно. Практически все предлагаемые метрики (строки отлаженного кода, количество методов, количество аргументов командной строки) легко обмануть, а получить конкретные данные по большим проектам очень трудно, потому что крайне редко два программиста получают одинаковое задание.

Я основываюсь на данных профессора Стэнли Айзенштата (Stanley Eisenstat) из Йеля. Он ежегодно читает интенсивный курс CS 323, где большая часть практической работы состоит примерно из пяти заданий по программированию, рассчитанных на две недели каждое. Задачи достаточно сложны для обычного курса: разработать оболочку командной строки для UNIX, программу ZLW-сжатия файлов и так далее.

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

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

Первое, что я сделал с этими данными, это вычислил среднее, минимальное и максимальное количество часов, затраченных на каждую из двенадцати задач, а также стандартное отклонение. Вот результаты:

Первое, что бросается в глаза, — огромный разброс данных. Самые проворные студенты заканчивали работу в три-четыре раза быстрее средних и — ни много ни мало — в десять раз быстрее самых медленных. Стандартное отклонение огромно. Тогда я подумал: хмм, наверное, некоторые из этих студентов сделали просто-таки отвратительные реализации. И решил исключить студентов, у которых за 4 часа не получилась работающая программа. Поэтому я уменьшил выборку и взял данные только по 25% студентов с лучшим кодом и высшими оценками. Замечу, что оценки в классе профессора Айзенштата полностью объективны: они вычисляются по формуле, исходя из количества автоматизированных тестов, пройденных кодом, и ничего больше. За плохой стиль и задержку баллы не снимаются.

Итак, вот результаты лучшей четверти студентов:

Невелика разница! Для четверти студентов (лучших!) практически то же стандартное отклонение. Более того, если внимательно посмотреть на эти данные, станет ясно, что видимой зависимости между временем и оценкой нет. Вот типичный график данных для одной из задач. Я выбрал задание COMPRESS01 (реализация алгоритма сжатия Зива-Лемпеля-Уэл-ша) за 2001 год, потому что стандартное отклонение для него очень близко к общему стандартному отклонению.

Нечего здесь искать, в этом-то вся и суть. Качество работы и время, затраченное на нее, просто не коррелируют.

Я спросил об этом профессора Айзенштата, и он обратил мое внимание еще на одну деталь. Поскольку работы следует сдавать к определенному сроку (обычно это полночь), а опоздание влечет существенный штраф, многие студенты прекращают работу, не доведя проект до конца. Иными словами, максимальное время, затраченное на задачу, может оказаться низким потому, что времени между получением задания и сроком, когда его нужно сдать, просто не хватает. Если бы у студентов было неограниченное время для разработки программ (что чуть больше походило бы на реальную жизнь), разрыв оказался бы еще больше.

Эти данные нельзя назвать строго научными. Наверняка здесь не все достоверно. Некоторые студенты могли завышать время своей работы в надежде возбудить к себе сочувствие и получить более легкие задачи в следующий раз. (Как же! Задания CS 323 не менялись с 1980-х, когда этот курс слушал я.) Другие студенты могли занижать затраты, потому что плохо следили за временем. Тем не менее, думаю, не будет большой натяжкой считать, что эти данные показывают пятикратную или десятикратную разницу в продуктивности разных программистов.

Если бы единственной разницей между программистами была продуктивность, можно было бы попробовать заменить одного действительно хорошего программиста пятью средними. Но ничего не выйдет. А все потому, что закон Брукса гласит: «Подключение новых людей к опаздывающему проекту задерживает его еще больше» (Frederick Brooks, «The Mythical Man-Month. Essays on Software Engineering» 15, 1995). Один хороший программист, работающий над единственной задачей, не тратит времени на координацию действий и общение с коллегами. Пять программистов, работающих над той же задачей, должны согласовывать свои действия и общаться между собой. Это отнимает массу времени. Есть и другие преимущества работы минимальной командой. Человеко-месяц — это действительно миф.

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

Пять Антонио Сальери не напишут «Реквием» Моцарта. Никогда. Даже если будут работать над ним сто лет.

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

Команда разработчиков плеера Creative Zen может потратить годы на улучшение своего жалкого подобия iPod и все же никогда не выпустить ничего столь же прекрасного и элегантного, как Apple iPod. И им ничего не удастся откусить от рыночного пирога Apple по той причине, что у них отсутствует чудесный талант дизайнера. Просто нет его там, и все.

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

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

И в последние несколько лет мы видели множество прекрасных программ — настоящих высоких нот, — каких посредственным разработчикам просто не видать.

В 2003 году Nullsoft выпустила новую версию плеера Winamp, разместив на своем сайте такое объявление:

Новый крутой дизайн!

Новые клевые функции!

Почти все работает!

Всех развеселил последний пункт — «Почти все работает!». И все счастливы, довольны плеером, пользуются им, рассказывают о нем друзьям, считают, что Winamp — просто фантастика, и все потому, что они взяли и написали на своем сайте: «Почти все работает!». Круто, да?

Если подбросить еще программистов в команду разработчиков Windows Media Player — смогли бы они взять такую высокую ноту? Никогда в жизни. Потому что чем больше команда, тем скорее в ней найдется брюзга, который скажет, что написать у себя на сайте «большинство функций действительно работает» — непрофессионализм и ребячество.

Не говоря уже о комментарии «Winamp 3: чуть новее, чем Winamp 2!».

Вот за это мы и любим Winamp.

Но как только тупицы из AOL Time Warner прибрали эту игрушку к рукам, юмор с сайта исчез. Так и видишь их — злобных, завистливых и лицемерных, как Сальери в «Амадеусе», готовых задушить любое проявление творчества, не одобренное старушкой из Миннесоты, ценой отказа от всего, что заставило людей полюбить этот продукт.

Или давайте взглянем на iPod. Батарею заменить нельзя. То есть когда аккумулятор умирает, все очень грустно. Покупай новый iPod. На самом деле, Apple готова заменить аккумулятор, если вы отошлете свой iPod на завод, но стоит это почти 66 долларов. Вот так-то.

Почему нельзя заменить аккумулятор?

Мое предположение: дизайнеры Apple не захотели испортить идеально-гладкую поверхность своего прекрасного и соблазнительного плеера грубой крышкой аккумуляторного отсека с вечно ломающейся защелкой и швами, в которые набивается мусор из кармана, — как в любом дешевом бытовом приборе. iPod — самое совершенное бытовое электронное устройство из всех, когда-либо виденных мной. Он красив. Он приятен на ощупь, как гладкий речной камушек. Крышка аккумулятора могла бы полностью уничтожить это ощущение.

Apple приняла решение в пользу стиля. На самом деле, в iPod полно таких «стилевых» решений. А стиль — это нечто недоступное ста программистам Microsoft или двумстам промышленным дизайнерам компании с неуместным названием Creative, потому что у них нет Джонатана Айва (Jonathan Ive), и Джонатаны Айвы на дороге не валяются.

Что поделать, об iPod я могу говорить бесконечно. А это прекрасное пощелкивающее колесико управления! Apple потратила дополнительные средства, встроив динамик в сам iPod, чтобы эти щелчки доносились из-под самого колесика управления. Можно было воспроизводить щелчки через наушники, сэкономив на этом сущие гроши. Но с таким колесиком управления вы чувствуете, как послушен плеер. Людям нравится управлять. Люди счастливы, когда они управляют. Счастливы. Вы счастливы от того, что колесико щелкает, плавно и быстро реагируя на команды. Это не прочий карманный электронный хлам, который так долго запускается, что, нажав выключатель, минуту ждешь первых признаков жизни. Управляет ли человек таким устройством? Вряд ли. Где это видано, чтобы мобильный телефон сразу включался после нажатия кнопки!

Стиль.

Счастье.

Эмоциональная притягательность.

Это то, что делает программное обеспечение, фильм и бытовую электронику хитом. И если вы этого не понимаете, то даже решая проблему, ваш продукт не станет главным хитом, благодаря которому все сотрудники вашей компании разбогатеют и станут разъезжать на стильных, счастливых, ярких машинах вроде Ferrari Spider F1, и еще останется на что построить ашрам во дворе.

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

К сожалению, это не касается немассовой разработки ПО. Внутренний программный продукт редко бывает настолько важен, чтобы нанимать для его разработки звезд. Долли Партон не приглашают петь на свадьбах. Вот почему более удачную карьеру делают программисты реальных софтверных компаний, а не ИТ-сотрудники разных банков.

Рынок ПО сегодня напоминает игру, в которой «победитель забирает все». Кроме Apple, никто не зарабатывает на MP3-плеерах. Никто не зарабатывает на электронных таблицах и текстовых процессорах, кроме Microsoft. Да, я знаю, что они предприняли определенные шаги, чтобы избавиться от конкурентов, тем не менее факт остается фактом: в этой системе победитель забирает все.

Нельзя позволить себе занимать второе место, поставляя «приемлемый» продукт. Он должен быть очень хорошим, настолько хорошим, чтобы его заметили. Тот дар, который приносят по-настоящему талантливые программисты, — ваш единственный шанс быть замеченным. Вот и вся формула:

15 Фредерик Брукс «Мифический человеко-месяц, или Как создаются программные системы». — Пер. с англ. — СПб.: Символ-Плюс, 2000.