Новый взгляд на извечный вопрос: следует ли переписывать приложение с нуля или это «самая худшая стратегическая ошибка, которую может сделать разработчик программного обеспечения»? Оказывается, при работе со зрелой кодовой базой есть более двух вариантов ответа.
«Исходный код словно заржавел!» — Джоэл Спольски
Почти два десятилетия назад Джоэл Спольски устроил разнос Netscape за то, что она переписала кодовую базу браузера, в своём эпохальном эссе «Чего никогда нельзя делать». Он пришёл к выводу, что функционирующий софт абсолютно никогда не следует переписывать с нуля. У него было два основных аргумента:
- Кажущиеся мусором части кодовой базы часто включают в себя трудом заработанные знания о пограничных ситуациях и странных ошибках.
- Полная переделка — длительное предприятие, которое отвлекает от улучшения существующего продукта, что даёт козыри конкурентам.
Для многих выводы Джоэла стали догмой; в своё время они оказали большое влияние и на меня. Но в последующие годы я понял, что при некоторых обстоятельствах всё-таки есть смысл полной переделки продукта. Например:
- Иногда устаревшая кодовая база действительно не поддаётся восстановлению, так что даже простой апгрейд требует каскадных изменений в других частях кода.
- Оригинальные технологические решения могут помешать произвести необходимые улучшения.
- Или оригинальная технология может устареть, что затрудняет (или делает слишком дорогим) найм квалифицированных разработчиков.
Конечно, на самом деле многое зависит от обстоятельств. Да, иногда имеет смысл постепенный рефакторинг устаревшего кода. И да, иногда имеет смысл всё выбросить и начать сначала.
Но это не единственный выбор. Давайте взглянем на шесть историй и посмотрим, какие уроки можно извлечь.
1. Netscape
Код браузера трижды переписывали с нуля
Катастрофический переход Netscape с 5.0 на 6.0 стал поводом для вышеупомянутой статьи Джоэла Сполски и многих убедил, что так никогда нельзя делать.
Netscape Navigator вышел в 1994 году, в первые годы коммерческого интернета. Не прошло двух лет — и компания открыла эпоху доткомов, проведя IPO на $3 млрд.
Первым серьёзным конкурентом Netscape стал Microsoft Internet Explorer, который вышел в 1996 году.
В начале 1998-го Netscape ещё оставался ведущим браузером, но с большим трудом. Netscape был коммерческой программой, которая продавалась за $49, а Microsoft раздавала IE бесплатно и поставляла как браузер по умолчанию в Windows.
После выхода Netscape 4.0 компания объявила, что следующая версия станет бесплатной и будет разработана сообществом open source, созданным и финансируемым компанией Mozilla. Для своего времени это был по сути беспрецедентный шаг, и Netscape приобрела много сторонников за такое смелое решение. Но в реальности это «сообщество» на самом деле так и не материализовалось. Джейми Завински, один из первых разработчиков браузера, объясняет:
Правда в том, что в состав участников проекта Mozilla входило около сотни штатных разработчиков Netscape и около тридцати внештатных, так что проект по-прежнему полностью принадлежал Netscape.
Команда пришла к выводу, что разработчики со стороны не заинтересовались проектом, в том числе по причине бардака в кодовой базе:
Код оказался слишком сложным и путанным для изменения, поэтому люди не вносили свой вклад… Вот почему мы перешли на новый движок. Более чистая, свежая кодовая база, которую легче понять и присоединиться к разработке.
С чистого листа
Таким образом, через год группа решила отказаться от 5.0, так и не выпустив релиз, и приступила к разработке версии 6.0 с нуля.
Подготовка Netscape 6.0 заняла целых два года; и даже после всего этого было ясно, что браузер сырой. По словам обозревателя New York Times Дэвида Пога, браузер запускался целую минуту (!) и поглощал оперативную память. У него отсутствовал ряд простых функций юзабилити, которые были в предыдущих версиях:
Исчезла функция предварительного просмотра печати, как и возможность перетаскивания значка адреса сайта прямо в меню закладок. Также нельзя скопировать или вставить веб-адрес в адресную строку, щелкнув его правой кнопкой мыши. И каждый раз в начале работы приходится изменять размер окна: Navigator не запоминает предыдущее состояние. Но самый неприятный недостаток — то, что нельзя выделить всю адресную строку одним щелчком мыши.
Но это уже практически не имело значения, потому что за три года, что Netscape стоял на месте, Internet Explorer захватил всю оставшуюся долю рынка:
Когда началась переработка браузера, Netscape быстро уступила позиции Microsoft Internet Explorer. Новый браузер вышел три года спустя, он был глючным и медленным; а рыночная доля Netscape тем временем сократилась почти до нуля (график адаптирован из Википедии)
В 1999 году, когда полным ходом шла переделка браузера, корпорация AOL приобрела Netscape за $10 млрд. Всего через два года после выхода Netscape 6.0 подразделение Netscape в AOL было ликвидировано.
Mozilla, сообщество с открытым исходным кодом, созданное Netscape, продолжит существование и выпустит браузер Firefox в 2002 году — ещё один проект с чистого листа. 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 стала известной благодаря влиятельному и часто противоречивому блогу, который вели основатели Джейсон Фрид и DHH.
Когда я только начинал заниматься веб-дизайном, они привлекли моё внимание серией статей с примерами неправильного дизайна и вариантами, как их переделать, для таких сайтов, как Google и PayPal. Проект назывался 37better.
Редизайн 37signals формы доставки FedEx (вверху) по-прежнему лучше реального дизайна, почти два десятилетия спустя
У компании была система управления проектами для внутреннего использования, которую они в 2004 году выпустили в качестве SaaS-сервиса под названием Basecamp.
В то время SaaS был ещё новинкой. Инструменты управления проектами продавались в коробках с четырёхзначными ценниками и увесистыми руководствами. Все они работали на концепции моделирования критических путей и рисовали сложные диаграммы Ганта. Basecamp продавался за $50 в месяц и стал глотком свежего воздуха со своим суперпростым интерфейсом и ориентацией на коммуникации.
Перенесёмся на несколько лет вперед, У Basecamp полмиллиона счастливых пользователей, платежи поступают каждый месяц, но Джейсон и Дэвид начали беспокоиться.
Несколько лет назад Дэвид рассказал эту историю на конференции Business of Software. Он признался, что находился под влиянием Джоэла Спольски и верил, что переписывание программного обеспечения убьёт компанию. Кроме того, был некий элемент самодовольства и уверенности в собственной правоте в связи с популярностью движения Agile:
[Меня] полностью поглотила идея трансцендентного ПО… Бесконечно пластичный код. Бесконечно ценное легаси. Вы можете изменить что угодно, переписать любую программу, любой код… Если программное обеспечение трудно изменить, сам виноват. Ты плохой программист, значит, нужно совершенствоваться.
Однако после «семи жирных лет» компания оказалась в затруднительном положении — и проблема не имела ничего общего с техническим долгом.
Золотые наручники
Всё началось с того, что ребята заметили в себе недостаток энтузиазма. Мало того, что не хватало мотивации работать над флагманским продуктом, так они и сами особо не пользовались своей программой.
У них имелось много идей, как сделать продукт принципиально лучше, но любое изменение нарушит привычные рабочие процессы сотен тысяч пользователей Basecamp. Проблема была не в сложной кодовой базе, а в пользователях.
Из-за стремления угодить существующим клиентам продукт остановился в развитии, что мешало привлечь новых пользователей. Это не угрожало бизнесу напрямую, но создавало долгосрочную угрозу. DHH метафорически сравнил ситуацию с дырявым ведром:
Вы можете заткнуть все дырки, исправить все ошибки, обновить все функции, на которые жалуются существующие клиенты — но часть воды всегда вытекает. Клиенты уходят с работы и оставляют программное обеспечение, даже если оно им [нравится]. Вы можете ввести себя в заблуждение: «Эй, ведро заполнено более чем наполовину. Тут просто маленькая дырочка, всего маленькая утечка, это совершенно естественно». Но, если ситуация сохранится, ведро полностью опустеет.
Часть проблемы в том, что вы постоянно слушаете нынешних клиентов, но не слышите будущих:
Люди, которые заходили на страницу Basecamp в 2011 году и отказывались покупать продукт, потому что он их уже не устраивал: как думаете, насколько часто мы слушали их мнение? Никогда. Мы слушали только широкую базу существующих клиентов, которые очень хотели, чтобы мы просто продолжали затыкать эти маленькие дырки.
Разработчики стали рассматривать прибыльный продукт как пару золотых наручников:
Главное убедиться, что все нынешние пользователи довольны. Деньги приходят каждый месяц, новый чек, новый чек, новый чек. Отлично. Но тогда вытяните руки и признайте: «Всё, я больше никогда не изменю свое программное обеспечение».
Спойлер: Basecamp переписали с нуля, и получилось здорово. Это заняло около года, и сразу после выпуска Basecamp 2 количество новых регистраций удвоилось.
Мне кажется, они сделали две главные вещи.
Во-первых, не пытались переделать прежний продукт — потому что в первую очередь хотели реализовать новые идеи насчёт того, как нужно подходить к решению тех проблем, которые решал старый продукт.
Неужели мы настолько самонадеянны, чтобы считать идеи 2003 года по-прежнему самыми лучшими идеями в 2011 году? Да, меня обвиняли в высокомерии, но весь пар вышел в 2008 году.
Таким образом, они представили Basecamp 2 как совершенно новый продукт, без каких-либо гарантий обратной совместим с Basecamp Classic. Появилось много нового, что-то вообще исчезло, а многое совершенно изменилось.
Это решение дало определённую степень свободы. Свобода мотивирует, а мотивированные люди лучше работают.
Помогло и отсутствие необходимости поддерживать каждый из вариантов использования оригинального продукта. Например, оригинальный Basecamp позволял размещать документы на собственном FTP-сервере. Разработчики удалили эту и другие подобные функции, которые раньше имели смысл, а сейчас стали маргинальными. Такое урезание ненужного функционала позволило вывести новый продукт на рынок в разумные сроки.
Закат считается вредным
Но что насчёт сотен тысяч существующих пользователей, у которых забирают любимую игрушку? Это подводит нас ко второй интересной вещи, которую сделали разработчики: они сохранили старый продукт.
Дэвид знатно проехался по термину «закат программного обеспечения»:
Кто-то где-то придумал прекрасный эвфемизм под названием «закат»… Назвать уничтожение программного обеспечения «закатом»… Типа все пользователи лежат на пляже — и с умилением наблюдают, как их информация исчезает. Это прекрасно!
Единственные люди, которые верят в «закат» — те, кто его так называет. Ни один пользователь, который действительно когда-либо проходил через период заката, не возвращается и не говорит: «О, это было красиво». Они возвращаются и говорят: «Чёрт! Я вложил сюда годы работы!.. И теперь ты собираешься меня закатить?!»
Он обратил внимание, что заставлять людей паковать вещи и двигаться — вот что «худшая стратегическая ошибка», потому что вы заставляете всех постоянных клиентов принимать решение, продолжать использовать ваше программное обеспечение или перейти на что-то другое.
Действительно ли мне нужен Basecamp? Если всё равно придётся переносить всё барахло, может, перенести его куда-нибудь ещё. Если нужно паковать вещи в коробки и загружать в грузовик, я могу просто отправить этот грузовик через весь город. Не такая уж большая проблема. Большая проблема — это упаковать все манатки. А уж куда переезжать, опять в Basecamp или в другое место, это уже второстепенный вопрос.
Дэвид сравнил Basecamp Classic с Leica M3: камера не производилась с 1967 года, но Leica обещает поддерживать и ремонтировать её до конца своих дней (фото: Dnalor 01)
Вместо этого Basecamp обязался «уважать своё наследие»: они упростили обновление на новую версию, но не требовали покидать Basecamp Classic. Кроме того, они обязались поддерживать Basecamp Classic вечно.
Прикол в том, что спустя четыре года они сделали это снова: в 2015 году вышел Basecamp 3, опять переписанный с нуля, с некоторыми новыми функциями и без некоторых старых, и опять многое изменилось. Как и раньше, пользователи более старых версий могут легко сделать апгрейд. Но если хотят, могут продолжать использовать Basecamp Classic или Basecamp 2 «до конца интернета».
Basecamp 3 не собирается ничего «закатывать». Не текущую версию, не классическую, оригинальную версию Basecamp. Какая-то из них хорошо работает для вас? Круто! Пожалуйста, продолжайте использовать её до конца интернета! Мы позаботимся о том, чтобы программы оставались быстрыми, безопасными и всегда доступными.
Но возникает много «но». Разве это не дорого? Поддержка нескольких версий требует много усилий? Что насчёт безопасности? Как насчёт устаревших кодовых баз? Что тут можно сказать. Мы просто заботимся о клиентах, даже если они не желают обновляться по нашему графику.
Выводы
Лично мне такая модель кажется действительно вдохновляющей.
Каждая переделка позволила Basecamp взглянуть назад и переделать продукт с учётом накопленного опыта. Для пользователей это беспроигрышная игра: консерваторы сохраняют свою игрушку; а инноваторы, которые сталкивались с ограничениями системы получают новое и, надеюсь, более продуманное приложение.
Конечно, поддержка нескольких версий бесконечно долгое время имеет свою цену; но, как говорит Дэвид:
Это не бесплатно. Конечно, нет. Это ценный продукт и конечно, поддержка не обходится бесплатно. Но она того стоит.
3. Visual Studio & VS Code
Примечание: значок хипстера
Microsoft сделала VS Code, чтобы достучаться до разработчиков на других платформах.
Вы должны помнить, что долгое время Microsoft предлагала «всё или ничего». Если вы использовали Visual Studio, то обязательно работали в .NET, и наоборот. Это разделило сообщество программного обеспечения на два больших, в основном взаимоисключающих лагеря — в ущерб всем.
Обращение к крутым ребятам
Ситуация стала меняться ещё в годы Стива Балмера: вспомните, насколько громким стало решение разработчиков ASP.NET не изобретать jQuery!
Одной из главных задач генерального директора Сатьи Наделлы стало обращение к разработчикам за пределами своего «огороженного сада».
Но была проблема. Вот что говорит Джулия Льюсон, вице-президент Visual Studio в этом выпуске подкаста The Changelog:
Мы ничего не могли предложить целому классу разработчиков: современным, веб-ориентированным, которые работают с Node и JavaScript — нам просто не о чем было с ними говорить. Этих разработчиков мы просто ничем не могли привлечь.
Таким образом, VS Code создавался, чтобы сломать этот барьер и сказать: «На самом деле знаете что, парни? У нас всё-таки есть кое-что полезное для вас».
Visual Studio — тяжеловесный продукт во всех смыслах: только установка может занять более получаса. Он поддерживает широкий спектр сложных вариантов использования, на которые полагаются корпоративные клиенты. Таким образом, не было смысла брать Visual Studio за отправную точку и добавлять функции в новом проекте на других платформах. И очевидно, что идея выпуска Visual Studio для Mac или Linux не особо поддерживалась.
Поэтому Microsoft начала с нуля, без гарантий обратной совместимости.
На самом деле, не совсем с нуля: у Microsoft уже были некоторые важные части, такие как редактор Monaco в браузере. И поскольку VS Code представляет собой приложение Node.js (написанное на Typescript и запущенное в Electron), то они воспользовались богатыми ресурсами экосистемы JavaScript.
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 за последние несколько лет превратилась в настоящий рай модулей с открытым исходным кодом. В этом отношении сейчас исторически беспрецедентное время.
4. Gmail и Inbox
Примечание: значок заката
Inbox for Gmail первоначально представили как альтернативный минималистичный UX для Gmail, «с фокусом на том, что действительно имеет значение». Он никогда не пытался соответствовать по функциональности оригинальному Gmail, а также представил новые функции: тематические группы (bundles), закреплённые письма и отложенные сообщения.
Некоторые пользователи, включая меня, с энтузиазмом приняли Inbox. Я всегда думал, что Inbox — демонстрационная версия того, чем в конечном итоге станет Gmail, поэтому мирился с отсутствием некоторых нюансов Gmail, ожидая, что они в конечном итоге доберутся до Inbox.
Два интерфейса, один сервис
Inbox и Gmail работали на одном бэкенде. По сути, это просто разные пользовательские интерфейсы для одной и той же службы, и вы могли переключаться туда и обратно по желанию. Это имело свои преимущества и недостатки: если в Inbox отсутствовала функция (скажем, автоответчик на время отпуска), вы всегда могли вернуться в Gmail и настроить что нужно, хотя переключение туда и обратно казалось странным.
Однако через некоторое время Inbox перестал улучшаться — стало ясно, что Google больше не вкладывает в него ресурсов. Естественно, через четыре года после запуска Google объявила о закате Inbox.
Как и всех остальных, сначала меня рассердило такое решение. Но проведя немного времени с последней версией Gmail, я обнаружил, что многие из моих любимых функций Inbox перенесены в оригинальный продукт: умный ответ, действия при наведении курсора, встроенные вложения и изображения. Несколько почтовых ящиков Gmail вполне сносно заменяют тематические группы Inbox.
Но не всё из Inbox перенесли в Gmail: например, люди настолько привыкли к «режиму паузы» (snoozing), что без него сейчас буквально физически страдают.
Выводы
Inbox дал возможность разработчикам Gmail экспериментировать с функциями, не нарушая рабочий процесс подавляющего большинства пользователей.
Однако обслуживая обе версии на одном бэкенде, Gmail поставил жёсткие ограничения на инновации.
Ещё раз, Google много критиковали за закрытие популярного сервиса. Конечно, Google постоянно закрываетсвои проекты, так что ничего неожиданного.
Но в этом случае первоначальное отношение Google к Inbox заставило поверить, что перед нами демонстрационная версия будущего Gmail. Как сказал бы DHH, закат вышел некрасивый: многим людям оказалось неприятно вернуться к старому продукту и потерять инновационные рабочие процессы Inbox.
Думаю, для многих переход дался бы гораздо проще, если бы перед закрытием Inbox все его функции интегрировали в Gmail.
5. FogBugz & Trello
Примечание: значки печального упадка и «деньги, деньги, деньги»
FogBugz — особенно интересный случай, поскольку это продукт самого Джоэла Спольски: он даёт представление о том, как принцип «никогда не переписывать» сталкивается с реальной жизнью.
До появления Jira и GitHub Issues существовала веб-система для отслеживания тикетов под названием FogBugz. Выпущенная в 2000 году, эта система стала первым продуктом новой компании Fog Creek Software, которую Джоэл основал с Майклом Прайором. И более десяти лет FogBugz оставался их флагманским продуктом. Изначально он продавался только как коробочная версия для установки на свои собственные серверы, но позже вышел вариант SaaS с оплатой по подписке.
FogBugz стал очень популярным, особенно среди разработчиков, которые по моему примеру читали блог Джоэла и принимали его советы близко к сердцу. Моя компания использовала систему много лет, это был отличный продукт для своего времени.
FogBugz первоначально написали на классическом ASP, который работал на серверах Windows. Когда вышел ASP.NET, Джоэл объяснил, почему не спешит обновляться.
Чтобы установить FogBugz на серверах Linux, стажёр компании написал компилятор Thistle для преобразования классического ASP в PHP. К 2006 году Thistle вырос в проприетарный язык программирования под названием Wasabi, который компилируется в ASP, PHP и клиентский JavaScript.
Странная история Wasabi
В наше время разработка собственного, проприетарного языка программирования и компилятора — это, скажем так, эксцентричный выбор. Так что интересно посмотреть, как всё происходило.
В какой-то момент Джоэл упомянул Wasabi в одном из сообщений в блоге. Некоторые подумали, что это шутка, поэтому он пояснил, что не шутка. У коллеги-блогера Джеффа Этвуда взорвалась голова от этой новости:
Писать на своём языке — это абсолютно за гранью. Это токсичное решение, которое настолько расходится с предыдущими отличными и здравыми советами Джоэла по разработке программного обеспечения, что люди в самом деле подумали, что он шутит.
Джоэл настаивал, что решение имеет смысл с точки зрения бизнеса. Конечно, чисто теоретически свой язык изобретать не стоит, но если оценить каждый маленький шаг на пути к принятию такого решения, учитывая тот технологический контекст и ту кодовую базу, то всё казалось логичным.
Размышляя над Wasabi в содержательном эссе под названием «Технический долг и поиск ветра», бывший инженер Fog Creek Тед Унангст сравнивает процесс с путешествием без карты:
Представьте, что вы находитесь в Саванне, штат Джорджия, и хотите поехать в Лондон, Англия. У вас нет карты, только смутное чувство направления… Вы не пойти по прямой, потому что у вас нет лодки, а перед вами океан. Но зато приятный пляж ведёт на северо-восток, а это примерно подходящее направление. Вы идёте по пляжу, идёте и идёте. Проходит время. Вы смотрите и видите, что с каждым шагом всё ближе к цели, хотя не двигаетесь к ней напрямик.
Где-то в Бостоне, или в Новой Шотландии вы наконец останавливаетесь и думаете о своём выборе. Может эта дорога не ведёт в Лондон? Далеко на галёрке слышен смех: «Ха-ха-ха, посмотри на этих дебилов. Не видят разницы между Англией и Новой Англией. Дайте этим дуракам карту». Но именно в этом проблема: у тебя нет карты. Карты делают люди, которые почти по определению не знают, куда идут.
В любом случае, объясняет Джейкоб Кралл, ещё один бывший разработчик Fog Creek, то решение принесло в жертву завтрашнюю ремонтопригодность ради сегодняшней скорости разработки. И к 2010 году стали приходит счета по этому долгу.
Мы не выложили [Wasabi] в open source, поэтому несли затраты в одиночку, за счёт своих основных прибыльных продуктов… Это была огромная зависимость, которая требовала наличия постоянного разработчика на одном этом продукте: недёшево для компании нашего размера. Иногда компилятор ругался на кусок кода, который выглядел вполне разумно для человека. Он медленно компилировал. Visual Studio не мог легко редактировать или подключить отладчик к FogBugz… Всех новых сотрудников сначала долго обучали Wasabi, независимо от их предыдущего опыта… Кроме того, мы жили не в вакууме. Языки программирования, конечно, улучшались за пределами Fog Creek… Разработчики начали чувствовать, что их блестящие идеи сталкиваются с ограничениями нашей маленькой вселенной Wasabi.
Точка перегиба
К тому времени FogBugz исполнилось уже десять лет: это был зрелый и стабильный продукт. В качестве побочного проекта Джоэл запустил Stack Overflow совместно с Джеффом Этвудом (очевидно, взорванная голова Джеффа к тому времени успела зажить).
FogBugz постепенно старел. Хотя рынок баг-трекеров оставался фрагментированным, на первый план стала выходить Jira от Atlassian, которая вышла через пару лет после FogBugz. Она стала выбором по умолчанию, особенно для крупных корпоративных пользователей.
На эту конкретную точку перегиба в истории FogBugz действительно интересно посмотреть со стороны. Как и у Basecamp, у них был прибыльный, зрелый продукт. Да, уже не такой модный и может над ним было не очень интересно работать. Хорошо это или плохо, но он вобрал в себя многие годы технологических изменений и новые идеи о том, как решать одну конкретную проблему: трекинг багов.
Конечно, был вариант Basecamp: с учётом всего опыта взять и переписать FogBugz с чистого листа. Предполагаю, эта идея не зашла слишком далеко, ведь мы помним: «чего никогда нельзя делать», «худшая стратегическая ошибка» и так далее, и тому подобное.
Недавно мне попалась на глаза статья 2009 года, которую Джоэл написал для Inc. Magazine. Его авторская колонка под заголовком «Означает ли медленный рост медленную смерть?» по тону совершенно не похожа на обычную самоуверенную напыщенность: она звучит интроспективно, неуверенно, наполнена сомнениями. Джоэл беспокоится о быстром росте Atlassian, рассуждает, есть ли на рынке место для нескольких игроков.
Мне пришлось задуматься. У нас появился большой конкурент, который растёт намного быстрее нас. Компания закрывает большие сделки с крупными, корпоративными клиентами… Между тем, наш продукт намного лучше, и мы хорошо управляемая компания, но это, кажется, не имеет значения. Почему?
Он решает сделать две вещи. Во-первых, добавить все функции в FogBugz:
Задача команды разработчиков на 2010 год — устранить любую возможную причину, по которой клиенты могут купить мусор наших конкурентов только потому что есть некая маленькая функция, без которой они якобы абсолютно не могут жить. Честно говоря, не думаю, что это будет очень сложно.
Во-вторых, создать корпоративный отдел продаж. Джоэл признаётся, что здесь он не силён, и находит неприятной данную задачу.
Не знаю, как сработали эти меры. Последний раз Джоэл упоминал FogBugz в своём блоге в мае 2010 года, вкратце анонсировав новую версию.
Новая надежда
А произошло вот что:
В районе десятилетнего юбилея Fog Creek Software я начал думать: чтобы сохранить мотивацию наших сотрудников ещё на десять лет, нужно начать работу над чем-то новым.
Поэтому они разделились на две команды, каждая из которых делала прототип нового продукта. Победившая идея создана в духе канбан-доски — реальной офлайновой доски, которая часто используется в проектах по разработке программного обеспечения: обычно она выглядит как заметки, распределённые по столбцам на доске.
Джоэл представил эту программу как инструмент управления на более высоком уровне, чем FogBugz:
Честно говоря, со всем этим причудливым программным обеспечением для «управления проектами», я никогда не мог нормально отследить, кто над чем работает… Будучи основателем двух компаний, я шёл по коридорам и видел десятки людей, которым платят за то, чтобы сидеть за компьютерами… и я понятия не имел, правильно ли они выполняют свою работу или они считают важным то, что на самом деле может и неважно.
При создании Trello разработчики Fog Creek получили шанс использовать современные технологии:
Мы используем передовые технологии, поэтому не обходится без жертв. Раны наших разработчиков разбросаны по всему MongoDB, WebSockets, CoffeeScript и Node. Но зато теперь им интересно. На сегодняшнем напряжённом рынке труда талантливые программисты во многом решают, над чем хотят работать. Если вы дадите им интересный продукт… им понравится и они будут любить свою компанию.
Trello с самого начала поддерживал плагины, так что сторонние разработчики начали помогать:
У плагинов и API наивысший приоритет… Никогда не делайте самостоятельно продукт, если можете предоставить базовый API, и ценные пользователи… сделают его для вас. Для команды Trello действует правило, что если какая-то функция может быть реализована через плагин, то она должна быть реализована именно таким образом.
Программисты, конечно, сразу поняли пользу Trello, Но в инструменте не было ничего специфического для разработки конкретно программного обеспечения. Джоэл описал Trello как полезный инструмент для «всего, где вы хотите совместно с другими людьми вести список списков». Вскоре Trello начали применять для организации всего подряд: от еженедельных обедов до свадеб и собачих приютов.
В то время как FogBugz был вертикальным продуктом — ориентированным на определённую рыночную нишу — Trello являлся горизонтальным продуктом, подходящим для чего угодно. Джоэл считает правильным «горизонтальное движение» Fog Creek на том этапе:
Практически невозможно создать крупный горизонтальный продукт, полезный во всех сферах. Он не может быть дорогим, потому что вы конкурируете с другими горизонтальными продуктами, которые могут амортизировать свои затраты на разработку для огромного количества пользователей. Это высокий риск и высокая награда: такой путь не подходит для молодого стартапа, но хорошая идея для второго или третьего продукта от зрелой и стабильной компании, такой как Fog Creek.
Чтобы быстро масштабироваться на очень большое количество пользователей, изначально Trello предлагался бесплатно. Позже ввели бизнес-план.
В 2014 году Trello выделили в независимую компанию. Три года спустя её с более чем 17 миллионами пользователей продали за $425 млн. По иронии судьбы, покупателем стал Atlassian, старый заклятый враг Fog Creek.
Тем временем возвращаемся домой…
Fog Creek продолжила разработку ещё одного нового продукта, среды совместного программирования под названием HyperDev, которую позже переименовали в GoMix, а затем в Glitch.
В то же время система FogBugz прозябала в безвестности. В 2017 году кто-то решил, что FogBugz — вообще глупое название, и инженерные усилия пошли на ребрендинг продукта как Manuscript. Год спустя — всего несколько месяцев назад — Fog Creek продала продукт небольшой компании DevFactory, которая немедленно вернула название FogBugz.
Под руководством генерального директора Анила Дэша Fog Creek стала компанией с одним продуктом и сменила название на Glitch.
Выводы
У меня много мыслей по этому поводу.
Ключ к пониманию истории заключается в том, что Fog Creek всегда заботилась не столько о баг-трекинге, сколько о расширении возможностей программистов — начиная со своих собственных:
Главная задача: создать комфортные условия для работы. Мы сделали сотрудникам личные кабинеты, они летали только первым классом, работали 40 часов в неделю, получали бесплатный обед, кресла Aeron и лучшие компьютеры. Мы поделились нашей гениальной формулой с миром: отличные условия работы → отличные программисты → отличное программное обеспечение → прибыль!
С учётом этой «формулу» можно сделать логичный и ободряющий вывод: Fog Creek построил бизнес вокруг счастья разработчиков. Это отразилось как на продуктах компании, так и на её внутренней «операционной системе». Первый продукт, баг-трекер, послужил основой для запуска нового продукта, который решил аналогичную проблему более абстрактным способом.
Со слов Джоэла похоже, что история Trello — поиск не столько нового бизнеса, сколько возможностей поддержать мотивацию и вовлечённость разработчиков Fog Creek. Продукт стоимостью полмиллиарда долларов стал просто приятным побочным эффектом.
Впрочем, немного грустно, как всё закончилось для FogBugz. Не думаю, что разработчики Fog Creek были особо счастливы в последние дни перед продажей.
Ясно, что были проекты поважнее и покрупнее: Stack Overflow, Trello и Glitch — каждый в отдельности гораздо полезнее и ценнее, чем FogBugz; и одному человеку невозможно уследить за всем. Поэтому я не могу никого винить, в частности, за потерю интереса к FogBugz с 20-летней кодовой базой и сильной конкуренцией на рынке. Но лояльные пользователи хотя бы нашли хороший дом и не получили лекарство типа «закат»!
Однако сентиментальная часть меня предпочла бы более достойно «почтить наследие» всех причастных к созданию и использованию этого продукта за минувшие годы.
6. FreshBooks и BillSpring
Примечание: значок «тайная операция»
Статья выросла больше, чем я предполагал, но не могу оставить в стороне эту историю. Держитесь, будет неожиданный поворот.
Остановите меня, если слышали это раньше
В начале 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 млн венчурного капитала, так что деньги имелись. Не все могут такое себе позволить.
Forbes оценивал выручку FreshBooks в 2013 году в $20 млн. После завершения обновления в 2017 году они заработали $50 млн. Неизвестно, сколько пришло от нового продукта, однако написание системы с нуля явно не замедлило рост компании.
МакДермент говорит, что процесс разработки и внедрения новых функций стал быстрее и проще. Ещё важнее, что теперь в их руках появился продукт, в котором реализованы лучшие идеи. С таким не страшно смотреть в будущее.
Кроме того, полученный опыт изменил культуру компании — в хорошем ключе. Когда они притворялись стартапом, то научились работать как стартап. Практики Lean UX распространились на всю команду разработчиков. Клиенты принимают активное участие в разработке новых функций.
FreshBooks пошёл на экстраординарные меры, чтобы оградить себя от потенциальных проблем: внедряя инновации под липовым брендом, разработчики могли полностью переосмыслить программу и принять на себя большие риски. Даже в худшем случае они не повредят существующему бренду.
Всё это кажется немного экстремальным. Возможно, в таких мерах не было необходимости. Но это напоминание о том, насколько серьёзны ставки.
Некоторые мысли
Общепринято мнение, что лучше избегать переписывания программы с нуля, а по возможности делать постепенные улучшения. По большей части, я с этим согласен.
Но совет предполагает, что в итоге мы получим оригинальный продукт плюс набор новых функций.
Но что делать, если вы хотите удалить функциональность? Или реализовать какую-то опцию совершенно иначе? Что делать, если с опытом пришли идеи принципиально нового подхода?
Мой вывод из этих историй таков: как только вы поняли, что текущая версия сильно отличается от воображаемого идеала, то новую версию следует выпускать не на замену, а параллельно с текущей.
Когда возникают мысли переписать всё с нуля, может, стоит задать другие вопросы. Может, создать собственного конкурента? Если мой продукт FogBugz, то что будет моим Trello? Если это Visual Studio, как будет выглядеть мой VS Code?
Если сравнить статью Спольски о Netscape и пост DHH про Basecamp, то они согласны в одном: у легаси есть ценность.
Хорошая новость в том, что вам не нужно выбрасывать эту ценность, чтобы внедрять инновации.
Автор: m1rko
