План выбросить одного прочь
Рассказ о Ruby.
В этом, 2017 году, Cooper отмечает свое 25-летие. Мы планируем вечеринку, все вспоминают истории из первых дней жизни, а мы вспоминаем уроки, которые извлекли из них. Это рассказ из еще более раннего времени, но урок остается таким же значимым.
Раньше считалось, что чем больше кода можно отправить, тем больше денег можно заработать. Но один из самых важных уроков цифровой эры заключался в том, что код может быть не только активом, но и помехой.
Но человеческая природа такова - большую часть времени ошибается - люди хотят видеть результаты. Они хотят видеть движение вперед, хотя это всего лишь иллюзия.
В нашей деловой среде, столь зависящей от инноваций и творчества, нам необходимо правильно подходить к решению этой проблемы. Иногда творчество очень похоже на то, как люди тратят время, играют в игры, мечтают или просто стоят в душе, глядя в пространство. Обычно это выглядит глупо. Люди хотят видеть, как заливался бетон и строились мосты. Они хотят видеть видимый прогресс и измеримый рост.
На самом деле, это просто крики о помощи. Они могут утверждать, что большой успех требует много работы, но при этом забывают, что люди так же усердно работали над огромными бедствиями. Они игнорируют обратную сторону и видят только преимущества. По словам пионера цифровых технологий Фредерика Брукса, «часто можно получить что-то бесплатно, если до этого ничего не купил».
Фредерик Брукс написал одну из самых первых книг, философски размышляющих о практике разработки программного обеспечения. В 1975 году он опубликовал блестящий сборник эссе под названием «Мифический человеко-месяц». Если вы купите два экземпляра книги, вы сможете прочитать ее в два раза быстрее.
Одна из его глав была озаглавлена «План по отказу от одного», где он сделал революционное заявление о том, что ценность написания кода - это то, что вы узнали из упражнения, а не код сам по себе. В конце 80-х у меня была уникальная возможность доказать истинность утверждения Брукса в игре по разработке программного обеспечения с высокими ставками.
В 1988 году, когда я занимался изобретением классного программного обеспечения и продажей его издателям, я написал язык визуального программирования, который назвал Ruby (никакого отношения к языку программирования, изобретенному десятью годами позже). Когда я показал его Биллу Гейтсу, он поразил его. Он купил его на месте, заявив, что это повлияет на всю их продуктовую линейку. Наконец, он был выпущен для широкой публики как Visual Basic и действительно повлиял на большинство продуктов Microsoft.
Но вначале у меня был только прототип. Это было около 15 000 строк уродливого кода C. На основе этого я написал подробную спецификацию, описывающую продукт, , а затем выбросил Ruby прототип.
Билл Гейтс хотел, чтобы Ruby поставлялась вместе с грядущей версией Windows 3.0, поэтому он передал управление Ruby Рассу, который отвечал за 3,0. Расс был молодым и дерзким руководителем, наделенным властью, но напуганным. Я обычно шутил, что Microsoft дала новым руководителям компьютер, стол и достаточно веревки, чтобы они могли повеситься. Расс был хорош, и выпуск 3.0 в конечном итоге будет считаться первой успешной версией Windows.
Но когда Расс узнал, что я отказался от Руби, он испугался. Он начал кричать на меня, говоря, что я не уложусь в сроки, сорву весь проект и задержу отгрузку всего продукта 3.0.
Поставив его перед свершившимся фактом, он мало что мог сделать, кроме как предсказать провал, но я знал, что Брукс был прав, и если начинать с нуля, это ускорит процесс, а не замедлит его.
В конце концов, я доставил окончательного мастера Руссу вовремя, а его часть проекта была отправлена с опозданием на восемь месяцев. Несмотря на то, что это нелогично, выбросить код может быть быстрее и эффективнее, чем пытаться превратить экспериментальный прототип в готовый продукт.
По определению, создание инновационных вещей требует выполнения вещей, которых раньше не делали. Таким образом, создание инновационного продукта на полпути, а затем его выброс и повторная сборка до завершения не только займет меньше времени, чем создание его один раз, но и приведет к созданию гораздо лучшего продукта, как с инженерной точки зрения, так и с точки зрения пользователя. .
Вот эссе 1996 года о том, почему они называют меня« Отцом Visual Basic ».
