Netscape потеряла компанию, а FogBugz создала успешный Trello: шесть историй, когда пришлось переписать код с нуля Статьи редакции

Перевод материала основателя компании-разработчика DevResults Херба Коудэлла.

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

Оказывается, существует больше двух способов работы с уже сложившейся кодовой базой.

Будто бы исходный код может испортиться!

Джоэл Спольски

Почти двадцать лет назад Джоэл Спольски написал знаменитую статью «Так делать не надо», в которой раскритиковал компанию Netscape за то, что она переписала свою кодовую базу.

Он пришёл к выводу, что работающее приложение ни при каких условиях не стоит переписывать с нуля. Спольски опирался на две идеи:

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

Для многих выводы Спольски стали своего рода догмой. В то время они оказали большое влияние и на меня.

Позже я ознакомился с противоположной точкой зрения — при определённых обстоятельствах больший смысл имеет переработать код с нуля.

  • Иногда база унаследованного кода испорчена настолько, что не поддаётся исправлениям. Получается снежный ком: переписываешь маленький фрагмент кода, который влечёт за собой ещё больше исправлений.
  • Внести необходимые улучшения иногда невозможно из-за использованных изначально технологий.
  • Либо эти технологии устарели, и поиск нужных разработчиков отнимет много усилий (или средств).

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

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

(Бонус — ASCII-рисунки с кратким пересказом каждой истории!)

1. Netscape

Подсказка: 📝= новый код, 💀 = тупик

Крайне неудачно переписанный код Netscape 5.0 и 6.0 благодаря Спольски стал олицетворением мантры «никогда не пиши заново».

Браузер Netscape Navigator, выпущенный в 1994 году, стал основой раннего интернета. Не прошло и двух лет с момента его выпуска, как IPO объёмом в $3 млрд запустило эру интернет-компаний.

Первым серьёзным конкурентом Netscape стал Internet Explorer от Microsoft, который вышел в 1996 году.

В начале 1998 года Netscape всё ещё был самым популярным браузером, но с небольшим отрывом. Розничная цена Netscape составляла $49, а Internet Explorer был бесплатным, и Microsoft поставляла его вместе с Windows в качестве браузера по умолчанию.

После выпуска версии Netscape 4.0 компания объявила, что версия 5.0 станет бесплатной и будет разработана с открытым кодом с помощью сообщества разработчиков, созданного и финансируемого компанией Mozilla.

Для того времени это было беспрецедентным решением, и таким бесстрашным ходом Netscape улучшила свою деловую репутацию. Однако Джейми Завински, один из первых разработчиков браузера, поясняет: «В состав проекта Mozilla входило около ста штатных и около тридцати сторонних разработчиков. Проект всё ещё полностью принадлежал Netscape».

Команда пришла к выводу, что одна из причин, почему разработчики не заинтересованы в проекте, — в существующей кодовой базе царила неразбериха.

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

Джейми Завински

С чистого листа

Итак, спустя год компания решила отказаться от работы над версией 5.0 и её выпуска и начала разработку версии 6.0 с нуля.

Прошло ещё два года, и Netscape 6.0 наконец выпустили, но стало ясно, что браузер всё ещё не готов. По словам обозревателя газеты The New York Times Дэвида Поуга, браузер запускался целую минуту и занимал много памяти. К тому же в нём отсутствовали простые пользовательские функции, которые были у предыдущих поколений браузера.

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

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

Дэвид Поуг

Но всё это уже не имело значения. За те три года, что Netscape провёл в тишине, Internet Explorer занял долю его рынка.

Когда код начали переписывать, Netscape стал быстро сдавал свои позиции Internet Explorer. Когда браузер выпустили, он оказался медленным и забагованным; доля рынка Netscape сократилась до минимума отредактированный график взят из «Википедии»

В 1999 году, в разгар переписывания кода, компания AOL приобрела Netscape за $10 млрд.

А всего через два года после выпуска Netscape 6.0 всю команду Netscape, работавшую внутри AOL, распустили.

Сообщество разработчиков с открытым кодом Mozilla, которое создала Netscape, выпустило браузер Firefox в 2001 году — после очередной разработки кода с нуля. Firefox удалось забрать небольшую долю рынка у Microsoft.

Но Netscape как коммерческое предприятие прекратило своё существование (Microsoft получит остатки интеллектуальной собственности Netscape в результате сделки с AOL в 2012 году).

Выиграв эту битву, Microsoft перестала инвестировать в технологии браузеров. Internet Explorer 6.0 вышел в 2001 году и не обновлялся на протяжении ещё пяти лет, что, по мнению некоторых, было осознанной стратегией, направленной на то, чтобы остановить развитие интернета как платформы для приложений.

Выводы

Некоторые утверждают, что в долгосрочной перспективе переписанный код не был катастрофой, так как в итоге он привёл к разработке движка Gecko и браузера Firefox.

Но нам пришлось пережить годы застоя веб-технологий под бесконечной, удушающей монополией IE6 в ожидании нового успешного браузера; и в конце концов, эре IE6 пришёл конец не благодаря Firefox, но благодаря Google Chrome.

В любом случае вопрос не в том, был ли переписанный код полезен интернету, а в том, было ли переписывание верным решением с точки зрения компании. Netscape оказался не у дел не только из-за кода — вердикт суда гласит, что Microsoft преднамеренно злоупотребила монопольным положением.

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

2. Basecamp

В начале 2000-х годов компания 37signals из Чикаго, занимавшаяся разработкой сайтов, набрала популярность за счёт влиятельного и зачастую провокационного блога её основателей Джейсона Фрида и Давида Хейнемейера Ханссона.

Когда я только начинал как веб-дизайнер, они привлекли моё внимание концептами дизайна таких сайтов, как Google и PayPal. Этот проект Фрид и Ханссон назвали 37better.

В 2004 году они взяли инструмент управления проектами, который сами разработали для внутреннего пользования, и выпустили его как облачную услугу под названием Basecamp.

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

Подписка на Basecamp стоила $50 в месяц, а простой интерфейс сервиса и упор на коммуникацию стали настоящим глотком свежего воздуха.

Проходит несколько лет, у Basecamp есть полмиллиона довольных пользователей, прибыль поступает каждый месяц, а Джейсону и Давиду не сидится на месте.

Я видел, как Давид рассказывал эту историю несколько лет назад на конференции Business of Software. Он сказал, что Джоэл Спольски убедил его в том, что полная переработка кода убьёт компанию. Основатель Basecamp, вдохновлённый методологией Agile, был излишне уверен в собственной правоте.

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

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

Давид Хейнемейер Ханссон

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

Золотые наручники

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

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

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

Можно продолжать исправлять баги, обновлять функции, на которые жалуются клиенты. Но сколько ни затыкай дыры — вода всё равно будет вытекать.

Покупатели меняют сферы деятельности. Даже если они любят твой продукт, перестают им пользоваться.

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

Давид Хейнемейер Ханссон

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

Как вы думаете, как часто мы слышали отзывы от людей, которые открывали главную страницу Basecamp в 2011 году и решали не покупать продукт, потому что мы им не подходили? Никогда.

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

Давид Хейнемейер Ханссон

Разработчики начали относиться к своему продукту как к паре золотых наручников.

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

Давид Хейнемейер Ханссон

Спойлер: переписали Basecamp с нуля, и всё получилось. Весь процесс занял примерно год, и количество новых пользователей увеличилось в два раза сразу после выпуска Basecamp 2.

По моему мнению, у них всё получилось благодаря двум интересным решениям.

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

Мы действительно так высокомерны, чтобы думать, что те идеи, которые у нас появились в 2003 году, всё ещё актуальны в 2011-м?

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

Давид Хейнемейер Ханссон

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

Такое решение дало определённую свободу. Свобода мотивирует, а мотивированным людям проще достичь целей.

Отсутствие необходимости в поддержке каждого варианта использования оригинального продукта тоже дало больше времени. Например, первая версия Basecamp позволяла пользователям хранить документы на их собственном FTP-сервере.

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

Закрытие проекта вредно

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

Дэвид некоторое время размышлял о «прикрытии» программ.

Кто-то когда-то придумал этот прекрасный эвфемизм — «закат программы» (sunset используется в значении «сворачивание, прекращение работы проекта» — vc.ru). Складывается ощущение, что все пользователи сидят на пляже и смотрят, как все их данные удаляются. Какая красота!

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

Они возвращаются и говорят: «Чёрт! Я несколько лет работы вложил в это! А вы теперь закрываетесь?».

Давид Хейнемейер Ханссон

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

Может, мне уже и не нужен Basecamp? Если нам в любом случае надо куда-то деть данные, почему бы не деть их в другое место? Если всё равно планируется переезд, то зачем хранить вещи в коробках?

Лучше перевезти эти коробки на другой конец города. Это не займёт много времени. Много времени займёт только собрать всё это. А разгружать ли вещи потом опять в Basecamp или где-то в другом месте, это не так важно.

Давид Хейнемейер Ханссон

Вместо закрытия сервис Basecamp решил «отдать должное наследию». Стартап сделал процесс обновления простым, но не обязательным. Помимо этого, пообещал бессрочно технически поддерживать и обеспечивать Basecamp Classic.

Самое интересное — компания проделала это ещё раз: в 2015 году вышел Basecamp 3, написанный с нуля. В обновлённом сервисе сервисе появились новые функции, исчезли или изменились старые.

Как и в прошлый раз, пользователи старых версий могли легко обновиться либо продолжать использовать Basecamp Classic или Basecamp 2 «до тех пор, пока существует интернет».

Давид сравнивает Basecamp Classic с фотоаппаратом Leica M3: его не производят с 1967 года, но компания Leica всё ещё предоставляет этой модели техническое обслуживание и планирует ремонтировать их, пока существует Фото: Dnalor 01

Basecamp 3 не приведёт к закрытиям других проектов. Ни текущей версии, ни классической оригинальной версии. Вам нравится с ними работать? Отлично! Продолжайте ими пользоваться, пока существует интернет. А мы обеспечим их скорость, безопасность и доступность.

Вы спросите: «Но разве это не дорого? Это же сложно? А как с безопасностью? А как же базы исходного кода?». Наша задача — забота о пользователях. Даже если они не хотят обновляться вместе с нами.

Давид Хейнемейер Ханссон

Выводы

Лично меня такая модель очень вдохновляет.

Каждая переработка кода позволяла компании Basecamp возвращаться к проектным решениям и создавать продукт, который она хотела создать ранее.

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

Бессрочно поддерживать несколько версий продукта довольно затратно. Но как говорит Ханссон: «Это стоит денег. С чего бы этому быть бесплатным? Это ценно, поэтому, конечно, не бесплатно. Но этого того стоит».

3. Visual Studio и VS Code

Подсказка: 😎 = хипстерский авторитет

Компания Microsoft создала редактор VS Code, чтобы наладить контакт с разработчиками, работающими на других платформах.

Следует помнить, что на протяжении долгого времени работа с Microsoft подразумевала отсутствие выбора. Если вы пользовались Visual Studio, то могли работать только на платформе .NET, и наоборот. Такой подход разделил сообщество программистов на два больших и по большей части полярных лагеря, что негативно отражалось на всех.

Дружба с современной аудиторией

Всё начало меняться ещё во времена Стива Балмера — вспомните, какой переполох был, когда команда ASP.NET решила не обновлять jQuery!

Одной из главных задач, которые генеральный директор Сатья Наделла поставил перед Microsoft, стало прямое привлечение разработчиков, находящихся вне золотой клетки компании.

Но вот что говорит Джулия Люсон, вице-президент Visual Studio, в одном из эпизодов подкаста The Changelog.

Мы ничего не могли предложить целому классу разработчиков — современным, мобильным, работающим с Node.js, JavaScript. Нам не о чем было с ними говорить и нечем привлечь. Поэтому причиной создания VS Code стало желание разрушить эту стену и сказать: «У нас есть кое-что, что может вам понравиться».

Джулия Люсон

Visual Studio — продукт тяжеловесный во всех смыслах этого слова: его установка может занимать до получаса. Он должен поддерживать широкий спектр сложных сценариев использования, на которые полагаются корпоративные клиенты. Так что стараться привлечь другие платформы, используя Visual Studio в качестве отправной точки и добавляя функции, для Microsoft не имело никакого смысла.

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

Вернее, не совсем с нуля: некоторые важные части уже были у Microsoft, например, браузерный редактор Monaco. А так как VS Code — приложение Node.js (написанном на TypeScript и работающим на базе Electron), компания могла воспользоваться развитой инфраструктурой JavaScript.

У VS Code открытый исходный код, он мало весит, быстрый и позволяет подключать расширения; а также — что удивительно для продукта Microsoft — он стал средой разработки кода, которую выбирают популярные ребята.

VS Code стал текстовым редактором, который выбирают JavaScript-хипстеры График из исследования состояния JavaScript за 2018 год

Оба продукта всё ещё находятся в активной разработке, и ничто не указывает на то, что Microsoft собирается закрывать Visual Studio.

Выводы

В отличие от Netscape, компании Microsoft удалось создать активное сообщество разработчиков с открытым кодом вокруг VS Code. Это сообщество приумножает результаты работы внутренней команды разработчиков.

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

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

Из всех проектов с открытым исходным кодом на GitHub Visual Studio Code занимает тринадцатое место по количеству звёзд — по случайному совпадению сразу за Linux

Ещё одним положительным моментом является то, что Microsoft снабдила VS Code надёжной моделью для расширения, в результате чего сообществом было написано более десяти тысяч расширений.

Финальный вывод, который можно сделать из истории VS Code, — за последние несколько лет мир изменился таким образом, что сейчас проще, чем когда-либо, создавать как программное обеспечение, так и его модели.

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

4. Gmail и приложение Inbox

Подсказка: 🌇 = «закат»

Приложение Inbox для Gmail было изначально представлено в качестве упрощённой альтернативы пользовательского интерфейса Gmail, «созданного только для того, что действительно важно». Его функциональность отличалась от функциональности Gmail, предлагала новые инструменты — такие как объединение писем в папки, закрепление писем и возможность поставить повторное оповещение о входящем письме.

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

Два интерфейса, один сервис

И Inbox, и Gmail использовали одинаковый бэкенд. Это было одно и то же, но с разными интерфейсами, между которыми можно было переключаться. У этого были как плюсы, так и минусы: если у Inbox отсутствовала какая-либо функция (например, автоматический ответ на входящие письма, когда вы уходите в отпуск), всегда можно было зайти в Gmail и сделать это там. Но переключаться туда-обратно не очень удобно.

Однако через какое-то время Inbox перестал улучшаться, и стало понятно, что Google прекратила тратить на него ресурсы. И действительно, по прошествии четырёх лет с момента запуска Google объявила, что проект Inbox закрывается.

Сначала это меня очень разозлило, но когда я потратил немного времени на знакомство с последней версией Gmail, то обнаружил, что многие функции перекочевали из Inbox в исходный продукт: функция Smart Reply, действия при наведении и встроенные вложения и картинки. Несколько папок для входящих сообщений у Gmail стали достойной заменой объединению писем в папки в Inbox.

Но в Gmail переместились не все функции: функция повторения оповещения, к примеру, была очень важной для многих людей, которые спланировали своё использование почты с её помощью; закрытие Inbox оставило их у разбитого корыта.

Выводы

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

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

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

Google заставила нас поверить, что нам представилась ранняя возможность посмотреть на будущее Gmail. Как сказал бы Давид Хейнемейер Ханссон, это не было «красивым закатом». Многим людям было крайне неудобно возвращаться к старому продукту и расставаться с прогрессивной организацией рабочего процесса в Inbox.

Я думаю, что недовольства было бы меньше, если бы Gmail полностью включил в себя функции Inbox перед его отключением.

5. FogBugz и Trello

Подсказка: 😟 = печальный конец, 🤑 = деньги, деньги, деньги

FogBugz особенно интересен, так как это продукт Джоэла Спольски, и он даёт нам представление о том, как принцип «никогда не переписывай код» работает с реальным продуктом.

До Jira и GitHub Issues существовал веб-продукт для отслеживания ошибок под названием FogBugz. Выпущенный в 2000 году сервис стал первым продуктом компании Fog Creek Software, фирмы, которую Джоэл на тот момент недавно основал вместе с Майклом Прайором.

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

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

Изначально FogBugz был написан на основе ASP, который работал на серверах Windows. Когда вышел ASP.NET, Джоэл объяснил, почему не хочет торопиться с обновлением.

Чтобы позволить устанавливать FogBugz на сервера Linux, стажёр написал компилирующую программу Thistle для преобразования классического ASP в PHP. К 2000 году Thistle превратился в особый язык собственной разработки под названием Wasabi, который мог выполнять компиляцию в ASP, PHP и клиентский JavaScript.

Странная история Wasabi

В наше время разработка собственного языка программирования и компилятора — это странное решение. Так что позвольте мне небольшое лирическое отступление, чтобы всё объяснить.

Однажды Спольски как бы между прочим упомянул Wasabi в конце материала в блоге. Некоторые посчитали, что он пошутил, и тогда он пояснил, что нет, это не шутка. Это взволновало его коллегу-блоггера Джеффа Этвуда.

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

Джефф Этвуд

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

В своей статье под названием «Технический долг и путь против ветра» бывший инженер Fog Creek Тед Унангст сравнивает этот процесс с попыткой пройти неизвестный путь без карты.

Представьте, что вы находитесь в Саванне, штат Джорджия, и хотите отправиться в Англию, в Лондон. У вас нет карты, но вы примерно представляете, в какую сторону идти.

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

Где-то в районе Бостона (или, может, Новой Шотландии) вы останавливаетесь и задумываетесь. А вдруг эта дорога не ведёт в Лондон? Откуда-то с галерки слышатся насмешки: «Ха-ха-ха, вы гляньте на этих придурков. Не могут Англию от Новой Англии отличить. Дайте им карту кто-нибудь».

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

Тед Унангст

Как бы то ни было, Джейкоб Кролл, ещё один бывший разработчик Fog Creek, объясняет, что это решение принято против скорости работы разработчика сегодня и в пользу лёгкости в сопровождении программы завтра, что является определением технологического долга. И к 2010 году настало время оплатить счёт за эту задолженность.

У Wasabi не было открытого кода, и это означало, что любая разработка требовала вложений с нашей стороны и за счёт наших других продуктов, которые приносили прибыль.

Мы сильно зависели от штатного разработчика, который для компании нашего размера стоил недёшево. Время от времени сервису Wasabi не нравился совершенно нормальный на наш взгляд кусок кода. Он медленно компилировал. Нельзя было с помощью Visual Studio легко отредактировать или подключить программу для поиска ошибок к FogBugz.

Все новые сотрудники (независимо от опыта работы) проходили длительный период обучения Wasabi.

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

Джейкоб Кролл, бывший разработчик Fog Creek

Переломный момент

По прошествии десятилетия FogBugz был зрелым и стабильным продуктом. Спольски также создал Stack Overflow вместе с Джеффом Этвудом (смею предположить, что к тому времени взорвавшийся мозг Этвуда восстановился).

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

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

Возможным решением было бы поступить так, как поступила Basecamp: взять всё, что компания Fog Creek узнала об отслеживании ошибок, и изобрести FogBugz заново, начиная с чистого листа.

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

Недавно я натолкнулся на статью 2009 года, которую Спольски написал, когда вёл ежемесячную колонку в журнале Inc. Magazine. Стиль его статьи «Медленный рост — это медленная смерть?» отличается от его обычной самоуверенной бравады — он более интроспективный, осторожный, полон сомнений.

Он переживает из-за быстрого роста компании Atlassian, размышляя над тем, неужели на рынке программ для отслеживания ошибок есть место только для одного продукта.

Я задумался. На нашем рынке присутствует крупный конкурент, который растёт намного быстрее нас. Та компания заключает сделки с крупными коммерческими клиентами.

Наш продукт намного лучше, компания хорошо управляется, но это почему-то не имеет значения. В чём причина?

Джоэл Спольски

В итоге он решает сделать две вещи. Во-первых, добавить все возможные функции в FogBugz.

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

Джоэл Спольски

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

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

Новая надежда

Вот что произошло.

Незадолго до десятилетнего юбилея Fog Creek Software я подумал, что если мы хотим поддерживать энтузиазм и мотивацию наших сотрудников ещё десять лет, нам необходимо начать работать над новыми вещами.

Джоэл Спольски

Так что разработчики разделились на команды по два человека в каждой, и эти команды начали работать над идеей и прототипом нового продукта.

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

Спольски представил её как улучшенную по сравнению с FogBugz программу для организации работы.

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

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

Джоэл Спольски

Создавая Trello, разработчики компании Fog Creek получили возможность работать с современными технологиями.

Мы используем самые свежие технологии. Зачастую это означает, что они сырые. Наши разработчики пытаются приготовить что-то из MongoDB, WebSockets, CoffeeScript и Node. И им это нравится.

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

Джоэл Спольски

Ещё Trello дал больше власти командам с собственными разработками, с самого начала разрешив внедрение сторонних плагинов.

Организация программного интерфейса и плагинов стоят во главе угла.

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

В команде Trello любая функция, которую можно оформить как плагин, должна быть оформлена как плагин.

Джоэл Спольски

Программистам Trello сразу же пришёлся по душе; но в продукте не было ничего, специально созданного для разработки программного обеспечения. Спольски говорил, что сервис будет полезен для любой работы, требующей создания списка списков для большого количества людей. Trello начали использовать для организации всего: от ужинов и свадеб до работы приюта для животных.

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

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

Здесь работает принцип «кто не рискует, тот не побеждает», но молодому стартапу не стоит его придерживаться. Но вот для второго или третьего продукта взрослой стабильной компании вроде Fog Creek он подходит.

Джоэл Спольски

Чтобы быстро набрать большое количество пользователей, сначала Trello был бесплатным. Позже появилась возможность подключить платный премиум-аккаунт.

В 2014 году из Trello создали отдельную компанию. Три года спустя количество пользователей перевалило за 17 миллионов, и Trello продали за $425 млн. По иронии судьбы покупателем оказалась Atlassian, старинный враг Fog Creek.

Тем временем в штаб-квартире

Компания Fog Creek создала систему для совместной разработки, которая сначала называлась HyperDev, потом GoMix, а затем Glitch.

А FogBugz в это время прозябал в забвении. В 2017 году кто-то решил, что FogBugz — дурацкое название, и сменил его на Manuscript, проведя вместе с тем технические работы и ребрендинг. Год спустя, всего несколько месяцев назад, Fog Creek продал своё детище небольшой компании под названием DevFactory, которая первым делом вернула название FogBugz.

Под началом генерального директора Анила Дэша Fog Creek стала поддерживать только один продукт и сменила своё название на Glitch.

Выводы

На меня эта история произвела сильное эмоциональное впечатление.

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

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

Формула, которую мы использовали и делились с другими: отличные условия работы → отличные программисты → отличные программы → прибыль!

Джоэл Спольски

Пользуясь этой «формулой», история становится более последовательной и вдохновляющей: бизнес Fog Creek ориентировался на удовлетворение потребностей разработчиков. Это было заметно и в продуктах компании, и во внутренней системе управления. Первый продукт, программа для отслеживания ошибок, стал основой для нового, который решает похожие проблемы, но в гораздо больших сферах деятельности.

Если посмотреть на ту историю создания Trello, которую рассказывает Спольски, то становится понятно, что он не просто искал перспективы развития бизнеса, а скорее хотел сохранить энтузиазм и мотивацию разработчиков Fog Creek. По счастливой случайности получился продукт стоимостью в полмиллиарда долларов.

Но меня всё равно расстраивает судьба FogBugz. Не думаю, что разработчики были очень довольны, став свидетелями последних дней продукта в их компании.

Конечно, у всех были дела поважнее: Stack Overflow, Trello и Glitch оказались намного более полезными и ценными, чем FogBugz; да и нельзя успеть всё сразу. Поэтому в потере интереса к FogBugz, его двадцатилетней кодовой базе и маленькому, но конкурентному рынку сбыта некого винить. Да и преданным пользователям не пришлось переживать «закат», они получили новый хороший продукт!

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

6. FreshBooks и BillSpring

Подсказка: 🕵️‍♀️ = операция под прикрытием

Эта статья уже и так намного длиннее, чем я планировал, но я не могу не рассказать эту историю. Не отвлекайтесь, вас ждёт неожиданный сюжетный поворот.

Скажите, если вы уже слышали эту историю

В начале 2000-х годов у Майка МакДермента была небольшая дизайнерская компания. Он делал счета на оплату при помощи Word и Excel, полагая, что программы для бухгалтерского учёта слишком сложные для его запросов.

Такой способ работал, пока не перестал.

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

Майк МакДермент

Майк был дизайнером, а не программистом, но вместе с двумя соучредителями он смог собрать вполне неплохую программу, за использование которой несколько человек были готовы платить $10 в месяц. Только по прошествии четырёх лет бизнес начал приносить достаточно прибыли, чтоб Майк смог съехать от родителей.

Когда компании исполнилось десять лет (знакомо звучит?), FreshBooks приносила стабильную прибыль, имела свыше десяти миллионов пользователей и триста сотрудников.

Оставалась одна проблема: когда она смогла позволить себе нанять программистов-профессионалов, у компании был миллион строк кода, написанного основателями. Приглашённый аналитик изучил кодовую базу и сделал следующий вывод.

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

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

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

Мы понимали, что если FreshBooks хочет соответствовать и оставаться привлекательной для этой группы людей и через пять лет, то надо действовать.

Майк МакДермент

МакДермент придерживался общепринятого мнения по поводу переписывания кода с нуля.

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

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

Майк МакДермент

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

Возможно, вас удивит продолжение

В итоге МакДермент принял решение тайно создать «конкурента» FreshBooks.

Он зарегистрировал новую компанию под названием BillSpring в Делавере. У новой компании были свой сайт, свой бренд и логотип. Чтобы ничто не связывало две компании, он попросил внештатного юриста составить новое пользовательское соглашение.

В качестве руководства команда разработчиков воспользовалась книгой Джеффа Готелфа и Джоша Сайдена «Метод Lean-UX: как создать хороший продукт с помощью Agile-команды» и внедрила методы Agile, такие как Scrum-команды, еженедельные спринты с обзорными совещаниями вместе с реальными пользователями. МакДермент сказал сотрудникам относиться к себе как к стартапу, а к нему как к венчурному инвестору.

У вас четыре с половиной месяца. Если к этому времени вы выйдете на рынок, получите больше денег. Если нет, сворачиваемся.

Майк МакДермент

Команда успела закончить создание продукта с минимальной функциональностью за несколько дней до дедлайна. Купила Google AdWords, чтобы привлечь трафик на новый сайт. На первый год предоставила бесплатные аккаунты. Прошло немного времени — и у команды появились реальные пользователи, и она начала доводить продукт до совершенства.

После года работы подписка на BillSpring стала платной. Однажды стартап неожиданно убедился в эффективности продукта.

Нам позвонил кто-то, чтобы отменить подписку на FreshBooks. Он сказал, что хочет перейти в BillSpring. Хороший был день.

Майк МакДермент

Вскоре разработчики приоткрыли завесу тайны: объяснили пользователям BillSprings, что этот продукт стал заменой FreshBooks, а пользователям FreshBooks скоро станет доступна новая версия.

Клиентам FreshBooks начали приходить предложения попробовать обновление. Но оно было необязательным: если не понравится, можно вернуться к прежней версии.

Выводы

Тайное переписывание кода обошлось FreshBooks недёшево: МакДермент утверждает, что компания потратила на проект $7 млн. После десяти лет последовательного роста она заработала $30 млн предпринимательского капитала, так что средства на это были. Но не все могут позволить себе такие расходы.

По оценкам Forbes, выручка FreshBooks за 2013 год составила $20 млн. В 2017 году, после обновления, она составила $50 млн. В компании не раскрывают, какой процент от выручки пришёлся на новый продукт, но разработка точно не замедлила рост.

МакДермент добавляет, что теперь разработчики могут быстрее и проще добавлять новые функции. Ещё более важно то, что в будущем продукт сможет воплотить лучшие идеи.

Помимо целей, которых они добились, сотрудники заметили, что этот опыт привёл к позитивным изменениям в корпоративной культуре компании. То время, которое они «притворялись» стартапом, заставило относиться к компании как к стартапу. Lean-методика распространилась на всю техническую команду. Теперь пользователи максимально вовлечены в разработку новых функций.

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

Возможно, такой подход кажется слишком радикальным, а на самом деле нет необходимости заходить так далеко. Но он показывает, как высоки ставки.

Что происходит сейчас

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

В целом я согласен с этой точкой зрения.

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

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

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

Итак, вместо того чтобы размышлять над тем, стоит переписывать код или нет, посмотрите на свой продукт и спросите себя: «Может, лучше создать себе конкурента? Если мой продукт — FogBugz, то где мой Trello? Если мой продукт — Visual Studio, как бы выглядел мой VS Code?».

Если вы прочитаете материал Спольски про Netscape, а затем — текст Давида Хейнемейера Ханссона про Basecamp, вы увидите, что в одном их мнения сходятся — то, что вы создали, обладает ценностью.

Хорошие новости: вам не надо избавляться от этой ценности, чтобы привнести в продукт что-то новое.

0
5 комментариев
Zoibana

Спасибо! Шикарная статья

Ответить
Развернуть ветку
Дмитрий Чугреев

Читая книги Спольски (хорошие и интересные книги, в целом), всегда удивлялся такому сильному перекосу в сторону обеспечения комфорта программистов, вот это все "каждому по офису". Интересно было бы почитать, насколько поменялись его взгляды на управление после гибели FogBugz и взлета Trello и StackOverflow.

Ответить
Развернуть ветку
AS

Касаемо VS, имхо, наилучший подход у JetBrains. Они пилят «каркас» - IDEA, и выпускают на базе него версии для разных потребностей, расширенные плагинами.
А VS Code - ну, такое. VS и VS Code - два совершенно разных продукта, то есть им приходится держать две команды, частично дублирующих работу друг друга. А сам VS в итоге монстр, который умеет все на свете и поэтому дохера весит, долго устанавливается и тд.

Ответить
Развернуть ветку
Alex Lee

Прочел. Было интересно.

Ответить
Развернуть ветку
Макс Лысюк

Бомбический материал, огромное спасибо!

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда