Дороже разработки программ может быть только разработка плохих программ

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

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

Если же этап проектирования не выполняется прежде этапа программирования, то никакого толку от него не будет. Как-то от одного руководителя я услышал такую фразу: «Мы уже поручили нашим сотрудникам писать код, и я не собираюсь останавливать их». Посыл этого умника приблизительно такой: «Я успею соорудить парашют прежде, чем мы ударимся о землю». Звучит весьма смело, но я ни разу не видел, чтобы это сработало.

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

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

Цена упущенных возможностей

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

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

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

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

Издержки прототипирования

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

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

Вся суть хорошего программирования заключается в том, что вознаграждение придет позже. Сначала вы выкладываетесь на максимум, а уже потом пожинаете плоды своих трудов. В мире не так много задач, выполнение которых вручную будет стоить больше. Тем не менее однажды написанная программа может быть выполнена миллион раз без дополнительных затрат. Самой дорогой будет программа, которую запустят лишь раз. Самой дешевой – та, которая отработает десять миллиардов раз. Если абстрагироваться от несерьезных программ, вроде тех, что пишут в школьные годы, то можно увидеть, что экономика программного обеспечения претерпела странные изменения: самыми дешевыми программами являются те, что влекут больше всего затрат при разработке, а самыми дорогими – те, написание которых обходится в разы дешевле.

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

То же самое характерно и для программного обеспечения – манипуляции с его фундаментом могут повлечь гораздо бо́льшие неприятности, нежели изменения кода более высокого уровня.

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

Перенести кнопку от одного края диалогового окна к другому – это все равно что слегка сдвинуть кирпич под номером 998, а вот внесение изменений в код, отвечающий за отображение всех кнопок, – это сдвиг пятого кирпича. В этом случае объектно-ориентированное программирование и инкапсуляция данных – это защитные меры, единственная цель которых – уберечь программу от появления подобных рубцов. Фактически объектно-ориентированный подход превращает башню высотой в 1000 кирпичей в десять башен по 100 кирпичей.

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

 

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

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

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

К сожалению, некоторые разработчики пришли к выводу, что современные инструменты для быстрого прототипирования – например, Visual Basic – являются эффективным средством проектирования. Теперь, вместо того чтобы создавать качественный дизайн и проектирование продукта, они просто выдают крайне жалкое подобие программы при помощи инструмента визуального программирования. Этот прототип впоследствии обычно используется как основа для продукта. Жертвой таких призрачных выгод падает надежность продукта и срок его жизни. Вместо создания множества прототипов гораздо лучше удастся спроектировать дизайн продукта, воспользовавшись карандашом, листом бумаги и хорошей методологией.

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

Ах, как же сильно руководителю хочется сказать: «Не избавляйтесь от прототипа. Давайте положим его в основу реального продукта». Но такое решение нередко подводит к ситуации, когда продукт так никогда и не выходит на рынок. Программисты оказываются навеки прикованными к необходимости бесконечно возвращать программу к жизни после каждого сбоя, угрожающего ее работоспособности по мере ее развития. Подобно башне, где первые 25 кирпичей положены вкривь и вкось, не имеет значения, насколько ровно вы положите оставшиеся кирпичи, насколько скрупулезно выполняет каменщик свою работу и как крепко держит их строительный раствор – башня падет под силой гравитации где-то на высоте пятидесятого кирпича.

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

В 1988 году Билл Гейтс купил у меня программу под названием Ruby. Это был язык визуального программирования, который впоследствии объединили с продуктом Билла QuickBasic, превратив его в Visual Basic. То, что первоначально увидел Гейтс, было всего лишь прототипом, но он демонстрировал значимые подвижки в применении проектирования и технологии. (Взглянув на это впервые, он воскликнул: «Как тебе удалось это сделать?») К работе над проектом Ruby был также привлечен Расс Вернер, в то время руководивший разработкой Windows 3.0. Далее мы заключили сделку, согласно которой я должен был написать полноценную программу и довести проект Ruby до завершения. Первым делом я отбросил прототип и начал все заново, с чистого листа, руководствуясь лишь своим опытом и здравым смыслом. Когда об этом узнал Расс, он был страшно удивлен, зол и разъярен. Никто и никогда еще не поступал таким возмутительным образом, и потому он был убежден, что, отбросив прототип, мы тем самым сорвем сроки выпуска продукта. Но все уже свершилось, и, несмотря на опасения Расса, мы завершили создание программы строго по графику. Интеграция среды VB с языком Basic сделала этот продукт одним из самых удачных ранних релизов для Microsoft. В противовес этому событию выпуск Windows 3.0 задержался более чем на год, и с тех пор он пользовался дурной славой неполноценного продукта ввиду чрезмерного количества неиспользуемого кода, оставшегося от прототипа.

В большинстве своем далекие от технологий руководители придают особую ценность именно завершенному коду. Вне зависимости от степени его надежности они предпочитают его дизайн-проекту или даже совету людей, которые этот код писали, и делают это совершенно напрасно. Как-то мой коллега, занимающийся созданием программного обеспечения для автомобильных систем навигации, Клэй Колье, рассказал мне историю об одной системе, над которой работал по заказу крупной японской компании, изготовляющей электронные запчасти для автомобилей. По запросу клиента Клэй разработал прототип пользовательской системы навигации. Как и полагается хорошему прототипу, он подтверждал, что система в целом будет рабочей, но за пределами этого ее функционирование не отличалось надежностью. В один прекрасный день в США прилетел президент этой японской компании, изготовляющей электронные запчасти, и пожелал увидеть программу в действии. Коллега Клэя, назовем его Ральф, понимал, что отказать президенту компании никак невозможно, и решил показать ему демоверсию. Ральф встретил президента в аэропорту Лос-Анджелеса и усадил в автомобиль, который был специально оборудован прототипом навигационной системы. Все, в чем был уверен Ральф, – это что прототип может отобразить путь до офисов компании, но все прочие функции еще не проходили тестирование. К великой досаде Ральфа, президент попросил доставить его в какой-то незнакомый ресторан на ленч. Ральф не знал, где находится этот ресторан, и не мог точно понять, сможет ли прототип отобразить путь. Он скрестил пальцы и ввел в навигатор название ресторана. К его большому удивлению, навигатор начал выдавать инструкции: «Поверните направо в направлении Линкольна», «Перестройтесь в левую полосу» и т. д. Ральф покорно исполнял указания навигатора, в то время как президент безмолвствовал, размышляя о чем-то своем. Так продолжалось до тех пор, пока автомобиль не начал проезжать все более и более сомнительные районы, – вот тогда Ральф всерьез обеспокоился. В тот момент, когда компьютер велел остановить автомобиль, нервы Ральфа были на пределе. Кто-то подошел к автомобилю снаружи и распахнул дверь. К огромному облегчению Ральфа, это оказался служащий того самого нужного президенту ресторана. На лице президента засияла улыбка.

Как бы то ни было, успешная демонстрация прототипа отразилась на Ральфе отнюдь не самым благоприятным образом. Президент был так впечатлен функционированием «системы», что поручил Ральфу сделать на ее основе готовый продукт. Ральф запротестовал, заявив, что это была только проверка возможности реализации и что она недостаточно надежна, чтобы делать миллионы пользовательских устройств на ее основе. Президент и слышать ничего не хотел. Он своими глазами видел прототип в действии. Ральф уступил, и через восемь долгих лет его компания наконец-то выпустила первый работоспособный релиз продукта. Он работал медленно, содержал множество багов и сильно уступал даже более молодым, новым продуктам конкурентов. Газета New York Times окрестила его «полнейшей катастрофой».

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

* * *

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

Медведь-плясун

Даже в том случае, когда «потерпевшие» явно понимают, что взаимодействие с программным продуктом заставляет их чувствовать себя глупыми, они не могут открыто признать это, ведь такое поведение в среде ярых защитников продукта будет выглядеть просто как жалобы и нытье. Нытиков в обществе не приветствуют, так что «потерпевшие» испытывают сильное социальное давление – их вынуждают перейти в стан апологетов, оправдываться за свое «плохое» поведение и винить во всем самих себя. Но инстинктивно «потерпевшие» догадываются, что правы, несмотря на попытки сознательно убедить себя в некомпетентности. Программы действительно заставляют их чувствовать себя глупыми, и это факт, которого быть не должно. Если вы один из таких людей, то, вероятно, сейчас задаетесь вопросом: «А что значит „плохая программа“? Она ведь решает рабочие задачи, разве нет?» В последующей части главы я объясню свое понимание «плохого» в отношении программ.