При каждом изменении программы – будь то исправление ошибок или добавление функций – появляются новые рубцы. Именно поэтому программы следует выбрасывать и полностью переписывать каждые пару десятков лет. Рубцовая ткань с течением времени становится настолько толстой, что препятствует нормальной работе.
Прототипы по своей природе представляют собой программы, создаваемые в спешке и позволяющие проверить некоторые предположения. Чтобы быстро создать прототип, программист должен пожертвовать идеальным выравниванием кирпичей. Здесь не используются «правильные» структуры данных, информация бессистемна. Здесь не используются «правильные» алгоритмы, но используются любые подвернувшиеся фрагменты кода. Прототип начинает существование как масса рубцовой ткани. Он не может вырасти очень большим.
Некоторые разработчики пришли к прискорбному выводу, что современные инструменты для быстрого создания прототипов, такие как Visual Basic, представляют собой эффективные инструменты проектирования. Вместо того, чтобы заняться проектированием продукта, они наскоро создают крайне бледную версию продукта при помощи инструмента визуального программирования. Этот прототип, как правило, становится фундаментам продукта. Ради иллюзорных выгод в жертву приносится надежность продукта и продолжительность его жизни. Карандаш, лист бумаги и хорошая методология позволяют лучше спроектировать продукт, чем любое количество прототипов.
Для людей, не являющихся проектировщиками, визуализация формы еще не существующей программы затруднительна, а часто и невозможна. Для этих деловых людей прототипы исполняют роль инструмента визуализации. Поскольку прототип – это приближенная модель, созданная на основе существующих и доступных на момент разработки инструментов, он по определению полон временных компромиссов. Однако работающая программа, независимо от того, насколько плохо она работает, производит мощнейшее впечатление на тех, кому придется платить за ее разработку. Движущийся, пусть и хромающий, прототип обладает опасной силой, не соответствующей своей действительной ценности.
Силен соблазн руководителя сказать: «Не выбрасывайте прототип, используем его как фундамент настоящего продукта». Такое решение часто, в конечном итоге, препятствует появлению продукта на рынке. Программисты оказываются приговоренными к постоянной реанимации программы, дающей по мере своего развития смертоносные сбои. Это башня из кирпичей, где первые 25 кирпичей положили наудачу: независимо от того, насколько точно вы кладете все последующие кирпичи, насколько тщательно работает каменщик, насколько крепко держит строительный раствор, сила гравитации неизбежно разрушит башню где-то на пятидесятом уровне.
Ценность прототипа в знаниях, приобретенных в процессе его создания, а совсем не в коде. Мудрый разработчик Фредерик Брукс говорит: «Планируйте выбросить одну версию». Так или иначе, вы ее выбросите, так почему не запланировать это событие с самого начала?
В 1988 году я продал Биллу Гейтсу программу под названием Ruby, представлявшую собой язык визуального программирования, который в сочетании с продуктом Билла QuickBasic стал средой Visual Basic. Ruby была просто прототипом, но демонстрировала некоторые значительные новшества в подходе и технологии (при первом знакомстве с Ruby Билл спросил: «Как ты это сделал?»). Проектом Ruby стал заниматься тогдашний руководитель разработки Windows 3.0 Расс Вернер. По договору я должен был завершить разработку Ruby и представить полноценный продукт. Первое, что я сделал, – выбросил прототип и начал все с нуля, не имея ничего, кроме знаний и опыта. Когда Расс узнал об этом, он пришел в изумление, ярость и негодование. Он никогда не слышал о столь возмутительных действиях и выражал убежденность, что отказ от прототипа задержит выпуск продукта. Но это был уже свершившийся факт, и, несмотря на страхи Расса, мы сдали золотую мастер-копию в срок. После интеграции с языком Basic запуск среды VB стал одним из самых успешных для Microsoft. Windows 3.0, напротив, задержалась более чем на год и впоследствии пользовалась дурной славой из-за большого объема рудиментарного кода, унаследованного из прототипа.
В целом, далекие от технологии руководители ошибочно ценят завершенный код, независимо от его надежности, гораздо выше, чем замысел, или мнение тех, кто этот код писал. Коллега Клэй Колье (Clay Collier), занятый в создании программного обеспечения для автомобильных систем навигации, поведал историю о системе, над которой он работал по заказу крупной японской автоэлектронной компании. Клэй разработал по просьбе своего клиента прототип системы навигации. Как и подобает хорошему прототипу, он доказывал, что система будет работать, но в целом программа была едва функциональна. Однажды в США прилетел президент этой японской компании – производителя автомобильной электроники. Президент желал увидеть программу в действии. Коллега Клэя, назовем его Ральф, знал, что президенту из Японии отказать нельзя, придется сотворить демонстрацию. Ральф встретил президента в аэропорту на автомобиле, специально оборудованном прототипом навигационной системы. Ральф знал, что прототип может указать дорогу к офисам компании в Лос-Анджелесе, но остальные адреса даже не проверялись. К огорчению Ральфа, президент попросил отвезти его на ланч в конкретный ресторан. Ральф не знал, где находится ресторан, и вовсе не был уверен, что прототип сможет указать туда дорогу. Он скрестил пальцы и набрал название ресторана. К его удивлению, компьютер начал давать указания: «Повернуть направо на Линкольн-стрит», «Перестроиться в левый ряд», и так далее. Ральф послушно следовал указаниям, в то время как президент молча думал о чем-то своем, однако вскоре инструкции привели их в сомнительные районы города, так что Ральф забеспокоился. Его беспокойство достигло предела, когда он остановил машину по команде компьютера, и в этот момент кто-то распахнул дверь автомобиля снаружи. К бесконечному облегчению Ральфа, дверь открыл сотрудник ресторана. Президент расплылся в улыбке.
Успех демонстрации прототипа обернулся для Ральфа неприятностями. Президент настолько впечатлился работой системы, что захотел, чтобы Ральф превратил ее в готовый продукт. Ральф возразил, что прототип недостаточно надежен, чтобы стать основой миллионов устройств, но президент ничего не хотел слышать – он же видел, что прототип работает. Ральф согласился, и восемь долгих лет спустя его компания, наконец, поставила первую работающую версию продукта. Она работала медленно, с ошибками и уже не могла угнаться за новыми, более сильными конкурентами. Газета New York Times назвала его «очевидно слабым».
Компетенция и знания, приобретенные Ральфом и его командой в процессе создания неправильного прототипа, были гораздо более ценны, чем код. Президент этого не понял, оценив код выше, и в результате пострадала вся компания.
* * *
Если определять границы проекта разработки лишь в терминах фиксированных сроков сдачи и перечня функций, даже своевременная сдача продукта не сделает его желанным. Если же определять проект в терминах качества и удовлетворения потребностей пользователей, вы получите востребованный продукт, и сроки разработки не будут более длительными. Старая шутка Кремниевой Долины: «Как сделать небольшое состояние на программном обеспечении?» И ответ, конечно: «Начать с большого состояния!» Скрытые издержки проекта по разработке программного обеспечения, даже при опытном руководстве, достаточно велики, чтобы даже Дональд Трамп задумался. Гонки на яхтах и пристрастие к наркотикам в долгосрочной перспективе обходятся дешевле, чем неконтролируемое создание программного обеспечения.
Даже если уцелевшие осознают, что именно интерактивный продукт заставляет их чувствовать себя глупо, они находятся в окружении апологетов и, как правило, не могут говорить об этом, не выставляя при этом себя нытиками. Ворчунов не любят, поэтому люди испытывают сильное социальное давление, вынуждающее их присоединиться к поборникам, принести извинения, обвинить себя в плохой расторопности. Однако инстинкты уцелевших пользователей сильнее сознательных попыток компенсировать чувство неуверенности. Программы заставляют их чувствовать себя глупо, хотя так не должно быть. Если вы из таких людей, то, возможно, задаетесь вопросом: «Что он имеет в виду, говоря о некачественных программах? Ведь эти программы решают рабочие задачи?» В оставшейся части главы я опишу свое понимание качества.
Если это проблема, то почему ее до сих пор не решили?
Танцующие программы-медведи плохи тем, что большинство людей довольствуется неуклюжими танцами. Лишь увидев, как должен выглядеть настоящий танец, они начинаются подозревать, что за медвежьим шарканьем скрывается иной мир. Очень немногие из продуктов, основанных на программном обеспечении, демонстрируют настоящие танцы, и большинство людей даже не подозревает, что ситуацию можно улучшить, причем существенно. Большинство пользователей электронных таблиц и текстовых процессоров на современных компьютерах считают, что все проблемы, которые способен решить компьютер, уже были решены, и найденные решения как минимум адекватны. Такое представление далеко от истины. Бесконечное число задач, связанных с обработкой информации, еще не решено, а в большинстве случаев никто даже не рассматривал возможные решения.
