Хабрахабр

[Перевод] Шесть историй, как код переписали с нуля

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

«Исходный код словно заржавел!» — Джоэл Спольски

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

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

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

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

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

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



Код браузера трижды переписывали с нуля

0 на 6. Катастрофический переход Netscape с 5. 0 стал поводом для вышеупомянутой статьи Джоэла Сполски и многих убедил, что так никогда нельзя делать.

Не прошло двух лет — и компания открыла эпоху доткомов, проведя IPO на $3 млрд. Netscape Navigator вышел в 1994 году, в первые годы коммерческого интернета.

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

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

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

Правда в том, что в состав участников проекта Mozilla входило около сотни штатных разработчиков Netscape и около тридцати внештатных, так что проект по-прежнему полностью принадлежал Netscape.

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

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

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

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

0 заняла целых два года; и даже после всего этого было ясно, что браузер сырой. Подготовка Netscape 6. У него отсутствовал ряд простых функций юзабилити, которые были в предыдущих версиях: По словам обозревателя New York Times Дэвида Пога, браузер запускался целую минуту (!) и поглощал оперативную память.

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

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

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

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

Firefox удалось вернуть часть пользователей, которые ушли к Microsoft. Mozilla, сообщество с открытым исходным кодом, созданное Netscape, продолжит существование и выпустит браузер Firefox в 2002 году — ещё один проект с чистого листа.

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

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

Выводы

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

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

Речь о том, каков результат для компании. В любом случае, речь не о том, как сказался проект на интернете. Но конечно, решение переписать всё с нуля стало важным фактором и привело к конечному результату: разрушению компании стоимостью в миллиарды долларов и тысячам увольнений. Смерть Netscape нельзя полностью списать на эти причины: суд согласился, что Microsoft намеренно злоупотребила своей монополией. Поэтому я соглашусь с Джоэлом, что чистые последствия этого решения оказались катастрофическими.


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

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

Редизайн 37signals формы доставки FedEx (вверху) по-прежнему лучше реального дизайна, почти два десятилетия спустя

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

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

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

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

Бесконечно ценное легаси. [Меня] полностью поглотила идея трансцендентного ПО… Бесконечно пластичный код. Ты плохой программист, значит, нужно совершенствоваться. Вы можете изменить что угодно, переписать любую программу, любой код… Если программное обеспечение трудно изменить, сам виноват.

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

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

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

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

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

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

Часть проблемы в том, что вы постоянно слушаете нынешних клиентов, но не слышите будущих:

Никогда. Люди, которые заходили на страницу Basecamp в 2011 году и отказывались покупать продукт, потому что он их уже не устраивал: как думаете, насколько часто мы слушали их мнение? Мы слушали только широкую базу существующих клиентов, которые очень хотели, чтобы мы просто продолжали затыкать эти маленькие дырки.

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

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

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

Мне кажется, они сделали две главные вещи.

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

Да, меня обвиняли в высокомерии, но весь пар вышел в 2008 году. Неужели мы настолько самонадеянны, чтобы считать идеи 2003 года по-прежнему самыми лучшими идеями в 2011 году?

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

Свобода мотивирует, а мотивированные люди лучше работают. Это решение дало определённую степень свободы.

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

Закат считается вредным

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

Дэвид знатно проехался по термину «закат программного обеспечения»:

Это прекрасно! Кто-то где-то придумал прекрасный эвфемизм под названием «закат»… Назвать уничтожение программного обеспечения «закатом»… Типа все пользователи лежат на пляже — и с умилением наблюдают, как их информация исчезает.

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

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

Если всё равно придётся переносить всё барахло, может, перенести его куда-нибудь ещё. Действительно ли мне нужен Basecamp? Не такая уж большая проблема. Если нужно паковать вещи в коробки и загружать в грузовик, я могу просто отправить этот грузовик через весь город. А уж куда переезжать, опять в Basecamp или в другое место, это уже второстепенный вопрос. Большая проблема — это упаковать все манатки.


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

Кроме того, они обязались поддерживать Basecamp Classic вечно. Вместо этого Basecamp обязался «уважать своё наследие»: они упростили обновление на новую версию, но не требовали покидать Basecamp Classic.

Как и раньше, пользователи более старых версий могут легко сделать апгрейд. Прикол в том, что спустя четыре года они сделали это снова: в 2015 году вышел Basecamp 3, опять переписанный с нуля, с некоторыми новыми функциями и без некоторых старых, и опять многое изменилось. Но если хотят, могут продолжать использовать Basecamp Classic или Basecamp 2 «до конца интернета».

Не текущую версию, не классическую, оригинальную версию Basecamp. Basecamp 3 не собирается ничего «закатывать». Круто! Какая-то из них хорошо работает для вас? Мы позаботимся о том, чтобы программы оставались быстрыми, безопасными и всегда доступными. Пожалуйста, продолжайте использовать её до конца интернета!

Разве это не дорого? Но возникает много «но». Что насчёт безопасности? Поддержка нескольких версий требует много усилий? Что тут можно сказать. Как насчёт устаревших кодовых баз? Мы просто заботимся о клиентах, даже если они не желают обновляться по нашему графику.

Выводы

Лично мне такая модель кажется действительно вдохновляющей.

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

Конечно, поддержка нескольких версий бесконечно долгое время имеет свою цену; но, как говорит Дэвид:

Конечно, нет. Это не бесплатно. Но она того стоит. Это ценный продукт и конечно, поддержка не обходится бесплатно.


Примечание: значок хипстера

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

Если вы использовали Visual Studio, то обязательно работали в . Вы должны помнить, что долгое время Microsoft предлагала «всё или ничего». Это разделило сообщество программного обеспечения на два больших, в основном взаимоисключающих лагеря — в ущерб всем. NET, и наоборот.

Обращение к крутым ребятам

Ситуация стала меняться ещё в годы Стива Балмера: вспомните, насколько громким стало решение разработчиков ASP.NET не изобретать jQuery!

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

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

Этих разработчиков мы просто ничем не могли привлечь. Мы ничего не могли предложить целому классу разработчиков: современным, веб-ориентированным, которые работают с Node и JavaScript — нам просто не о чем было с ними говорить.

У нас всё-таки есть кое-что полезное для вас». Таким образом, VS Code создавался, чтобы сломать этот барьер и сказать: «На самом деле знаете что, парни?

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

Поэтому Microsoft начала с нуля, без гарантий обратной совместимости.

И поскольку VS Code представляет собой приложение Node.js (написанное на Typescript и запущенное в Electron), то они воспользовались богатыми ресурсами экосистемы JavaScript. На самом деле, не совсем с нуля: у Microsoft уже были некоторые важные части, такие как редактор Monaco в браузере.

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


VS Code стал основным редактором для JS-хипстеров (диаграмма из отчёта State of JavaScript Survey, 2018)

Оба продукта по-прежнему активно разрабатываются, и нет никаких признаков того, что Microsoft намерена закрыть Visual Studio.

Выводы

В отличие от Netscape, компании Microsoft действительно удалось создать вокруг VS Code активное open source сообщество. Оно приумножило усилия разработчиков по улучшению продукта.


Из всех проектов с открытым исходным кодом, Visual Studio Code занимает 13-е место по количеству звезд на GitHub — по совпадению, чуть ниже Linux!

Но если open source является частью вашей стратегии развития, есть смысл сравнить истории Microsoft и Netscape — и выяснить, что Microsoft сделала иначе, чтобы её сообщество процветало. Конечно, не каждая компания может позволить выкладывать свой основной продукт в свободный доступ.

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

Один из последних выводов из истории VS Code в том, что за последние несколько лет всё кардинально изменилось: в наши дни как никогда просто создавать прототипы и программное обеспечение.

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



Примечание: значок заката

Он никогда не пытался соответствовать по функциональности оригинальному Gmail, а также представил новые функции: тематические группы (bundles), закреплённые письма и отложенные сообщения. Inbox for Gmail первоначально представили как альтернативный минималистичный UX для Gmail, «с фокусом на том, что действительно имеет значение».

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

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

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

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

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

Но не всё из Inbox перенесли в Gmail: например, люди настолько привыкли к «режиму паузы» (snoozing), что без него сейчас буквально физически страдают.

Выводы

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

Однако обслуживая обе версии на одном бэкенде, Gmail поставил жёсткие ограничения на инновации.

Конечно, Google постоянно закрываетсвои проекты, так что ничего неожиданного. Ещё раз, Google много критиковали за закрытие популярного сервиса.

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

Думаю, для многих переход дался бы гораздо проще, если бы перед закрытием Inbox все его функции интегрировали в Gmail.



Примечание: значки печального упадка и «деньги, деньги, деньги»

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

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

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

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

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

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

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

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

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

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

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

У вас нет карты, только смутное чувство направления… Вы не пойти по прямой, потому что у вас нет лодки, а перед вами океан. Представьте, что вы находитесь в Саванне, штат Джорджия, и хотите поехать в Лондон, Англия. Вы идёте по пляжу, идёте и идёте. Но зато приятный пляж ведёт на северо-восток, а это примерно подходящее направление. Вы смотрите и видите, что с каждым шагом всё ближе к цели, хотя не двигаетесь к ней напрямик. Проходит время.

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

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

Иногда компилятор ругался на кусок кода, который выглядел вполне разумно для человека. Мы не выложили [Wasabi] в open source, поэтому несли затраты в одиночку, за счёт своих основных прибыльных продуктов… Это была огромная зависимость, которая требовала наличия постоянного разработчика на одном этом продукте: недёшево для компании нашего размера. Visual Studio не мог легко редактировать или подключить отладчик к FogBugz… Всех новых сотрудников сначала долго обучали Wasabi, независимо от их предыдущего опыта… Кроме того, мы жили не в вакууме. Он медленно компилировал. Языки программирования, конечно, улучшались за пределами Fog Creek… Разработчики начали чувствовать, что их блестящие идеи сталкиваются с ограничениями нашей маленькой вселенной Wasabi.

Точка перегиба

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

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

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

Предполагаю, эта идея не зашла слишком далеко, ведь мы помним: «чего никогда нельзя делать», «худшая стратегическая ошибка» и так далее, и тому подобное. Конечно, был вариант Basecamp: с учётом всего опыта взять и переписать FogBugz с чистого листа.

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

У нас появился большой конкурент, который растёт намного быстрее нас. Мне пришлось задуматься. Почему? Компания закрывает большие сделки с крупными, корпоративными клиентами… Между тем, наш продукт намного лучше, и мы хорошо управляемая компания, но это, кажется, не имеет значения.

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

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

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

Последний раз Джоэл упоминал FogBugz в своём блоге в мае 2010 года, вкратце анонсировав новую версию. Не знаю, как сработали эти меры.

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

А произошло вот что:

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

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

Джоэл представил эту программу как инструмент управления на более высоком уровне, чем FogBugz:

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

При создании Trello разработчики Fog Creek получили шанс использовать современные технологии:

Раны наших разработчиков разбросаны по всему MongoDB, WebSockets, CoffeeScript и Node. Мы используем передовые технологии, поэтому не обходится без жертв. На сегодняшнем напряжённом рынке труда талантливые программисты во многом решают, над чем хотят работать. Но зато теперь им интересно. Если вы дадите им интересный продукт… им понравится и они будут любить свою компанию.

Trello с самого начала поддерживал плагины, так что сторонние разработчики начали помогать:

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

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

Джоэл считает правильным «горизонтальное движение» Fog Creek на том этапе: В то время как FogBugz был вертикальным продуктом — ориентированным на определённую рыночную нишу — Trello являлся горизонтальным продуктом, подходящим для чего угодно.

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

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

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

Тем временем возвращаемся домой…

Fog Creek продолжила разработку ещё одного нового продукта, среды совместного программирования под названием HyperDev, которую позже переименовали в GoMix, а затем в Glitch.

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

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

Выводы

У меня много мыслей по этому поводу.

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

Мы сделали сотрудникам личные кабинеты, они летали только первым классом, работали 40 часов в неделю, получали бесплатный обед, кресла Aeron и лучшие компьютеры. Главная задача: создать комфортные условия для работы. Мы поделились нашей гениальной формулой с миром: отличные условия работы → отличные программисты → отличное программное обеспечение → прибыль!

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

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

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

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

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



Примечание: значок «тайная операция»

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

Остановите меня, если слышали это раньше

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

Всё нормально работало до одного случая:

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

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

К 10-летнему юбилею программы (звучит знакомо?) Freshbooks стала прибыльной фирмой с более чем 10 миллионами пользователей и 300 сотрудниками.

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

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

Что более важно, в существующем продукте невозможно было реализовать имеющиеся идеи:

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

МакДермент знаком с расхожим мнением, что нельзя переписывать систему с нуля:

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

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

Что произошло дальше, может вас удивить

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

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

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

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

Команде удалось выпустить MVP за несколько дней до дедлайна. Они купили ключевики AdWords для привлечения трафика, предложили пользователям бесплатные аккаунты на первый год. Вскоре появились клиенты — и начались быстрые циклы итерации настоящего продукта.

В какой-то момент новый продукт получил неожиданную оценку качества: По окончании первого года BillSpring стала взимать плату.

«Один человек позвонил, чтобы отменить подписку на FreshBooks и перейти в нашу новую компанию, — говорит МакДермент. — Это был отличный день».

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

Постепенно клиентов «классического» FreshBooks допустили к новой версии, но они всегда могли вернуться к старой, если захотели.

Выводы

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

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

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

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

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

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

Некоторые мысли

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

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

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

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

Может, создать собственного конкурента? Когда возникают мысли переписать всё с нуля, может, стоит задать другие вопросы. Если это Visual Studio, как будет выглядеть мой VS Code? Если мой продукт FogBugz, то что будет моим Trello?

Если сравнить статью Спольски о Netscape и пост DHH про Basecamp, то они согласны в одном: у легаси есть ценность.

Хорошая новость в том, что вам не нужно выбрасывать эту ценность, чтобы внедрять инновации.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть