Новый взгляд на извечный вопрос: следует ли переписывать приложение с нуля или это «самая худшая стратегическая ошибка, которую может сделать разработчик программного обеспечения»? Оказывается, при работе со зрелой кодовой базой есть более двух вариантов ответа.
Почти два десятилетия назад Джоэл Спольски устроил разнос 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 приобрела много сторонников за такое смелое решение. Но в реальности это «сообщество» на самом деле так и не материализовалось. Джейми Завински, один из первых разработчиков браузера, объясняет:
Команда пришла к выводу, что разработчики со стороны не заинтересовались проектом, в том числе по причине бардака в кодовой базе:
Таким образом, через год группа решила отказаться от 5.0, так и не выпустив релиз, и приступила к разработке версии 6.0 с нуля.
Подготовка Netscape 6.0 заняла целых два года; и даже после всего этого было ясно, что браузер сырой. По словам обозревателя New York Times Дэвида Пога, браузер запускался целую минуту (!) и поглощал оперативную память. У него отсутствовал ряд простых функций юзабилити, которые были в предыдущих версиях:
Но это уже практически не имело значения, потому что за три года, что 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 намеренно злоупотребила своей монополией. Но конечно, решение переписать всё с нуля стало важным фактором и привело к конечному результату: разрушению компании стоимостью в миллиарды долларов и тысячам увольнений. Поэтому я соглашусь с Джоэлом, что чистые последствия этого решения оказались катастрофическими.
В начале 2000-х годов чикагская студия веб-дизайна под названием 37signals стала известной благодаря влиятельному и часто противоречивому блогу, который вели основатели Джейсон Фрид и DHH.
Когда я только начинал заниматься веб-дизайном, они привлекли моё внимание серией статей с примерами неправильного дизайна и вариантами, как их переделать, для таких сайтов, как Google и PayPal. Проект назывался 37better.
Редизайн 37signals формы доставки FedEx (вверху) по-прежнему лучше реального дизайна, почти два десятилетия спустя
У компании была система управления проектами для внутреннего использования, которую они в 2004 году выпустили в качестве SaaS-сервиса под названием Basecamp.
В то время SaaS был ещё новинкой. Инструменты управления проектами продавались в коробках с четырёхзначными ценниками и увесистыми руководствами. Все они работали на концепции моделирования критических путей и рисовали сложные диаграммы Ганта. Basecamp продавался за $50 в месяц и стал глотком свежего воздуха со своим суперпростым интерфейсом и ориентацией на коммуникации.
Перенесёмся на несколько лет вперед, У Basecamp полмиллиона счастливых пользователей, платежи поступают каждый месяц, но Джейсон и Дэвид начали беспокоиться.
Несколько лет назад Дэвид рассказал эту историю на конференции Business of Software. Он признался, что находился под влиянием Джоэла Спольски и верил, что переписывание программного обеспечения убьёт компанию. Кроме того, был некий элемент самодовольства и уверенности в собственной правоте в связи с популярностью движения Agile:
Однако после «семи жирных лет» компания оказалась в затруднительном положении — и проблема не имела ничего общего с техническим долгом.
Всё началось с того, что ребята заметили в себе недостаток энтузиазма. Мало того, что не хватало мотивации работать над флагманским продуктом, так они и сами особо не пользовались своей программой.
У них имелось много идей, как сделать продукт принципиально лучше, но любое изменение нарушит привычные рабочие процессы сотен тысяч пользователей Basecamp. Проблема была не в сложной кодовой базе, а в пользователях.
Из-за стремления угодить существующим клиентам продукт остановился в развитии, что мешало привлечь новых пользователей. Это не угрожало бизнесу напрямую, но создавало долгосрочную угрозу. DHH метафорически сравнил ситуацию с дырявым ведром:
Часть проблемы в том, что вы постоянно слушаете нынешних клиентов, но не слышите будущих:
Разработчики стали рассматривать прибыльный продукт как пару золотых наручников:
Спойлер: Basecamp переписали с нуля, и получилось здорово. Это заняло около года, и сразу после выпуска Basecamp 2 количество новых регистраций удвоилось.
Мне кажется, они сделали две главные вещи.
Во-первых, не пытались переделать прежний продукт — потому что в первую очередь хотели реализовать новые идеи насчёт того, как нужно подходить к решению тех проблем, которые решал старый продукт.
Таким образом, они представили Basecamp 2 как совершенно новый продукт, без каких-либо гарантий обратной совместим с Basecamp Classic. Появилось много нового, что-то вообще исчезло, а многое совершенно изменилось.
Это решение дало определённую степень свободы. Свобода мотивирует, а мотивированные люди лучше работают.
Помогло и отсутствие необходимости поддерживать каждый из вариантов использования оригинального продукта. Например, оригинальный Basecamp позволял размещать документы на собственном FTP-сервере. Разработчики удалили эту и другие подобные функции, которые раньше имели смысл, а сейчас стали маргинальными. Такое урезание ненужного функционала позволило вывести новый продукт на рынок в разумные сроки.
Но что насчёт сотен тысяч существующих пользователей, у которых забирают любимую игрушку? Это подводит нас ко второй интересной вещи, которую сделали разработчики: они сохранили старый продукт.
Дэвид знатно проехался по термину «закат программного обеспечения»:
Он обратил внимание, что заставлять людей паковать вещи и двигаться — вот что «худшая стратегическая ошибка», потому что вы заставляете всех постоянных клиентов принимать решение, продолжать использовать ваше программное обеспечение или перейти на что-то другое.
Дэвид сравнил Basecamp Classic с Leica M3: камера не производилась с 1967 года, но Leica обещает поддерживать и ремонтировать её до конца своих дней (фото: Dnalor 01)
Вместо этого Basecamp обязался «уважать своё наследие»: они упростили обновление на новую версию, но не требовали покидать Basecamp Classic. Кроме того, они обязались поддерживать Basecamp Classic вечно.
Прикол в том, что спустя четыре года они сделали это снова: в 2015 году вышел Basecamp 3, опять переписанный с нуля, с некоторыми новыми функциями и без некоторых старых, и опять многое изменилось. Как и раньше, пользователи более старых версий могут легко сделать апгрейд. Но если хотят, могут продолжать использовать Basecamp Classic или Basecamp 2 «до конца интернета».
Лично мне такая модель кажется действительно вдохновляющей.
Каждая переделка позволила Basecamp взглянуть назад и переделать продукт с учётом накопленного опыта. Для пользователей это беспроигрышная игра: консерваторы сохраняют свою игрушку; а инноваторы, которые сталкивались с ограничениями системы получают новое и, надеюсь, более продуманное приложение.
Конечно, поддержка нескольких версий бесконечно долгое время имеет свою цену; но, как говорит Дэвид:
Примечание: значок хипстера
Microsoft сделала VS Code, чтобы достучаться до разработчиков на других платформах.
Вы должны помнить, что долгое время Microsoft предлагала «всё или ничего». Если вы использовали Visual Studio, то обязательно работали в .NET, и наоборот. Это разделило сообщество программного обеспечения на два больших, в основном взаимоисключающих лагеря — в ущерб всем.
Ситуация стала меняться ещё в годы Стива Балмера: вспомните, насколько громким стало решение разработчиков ASP.NET не изобретать jQuery!
Одной из главных задач генерального директора Сатьи Наделлы стало обращение к разработчикам за пределами своего «огороженного сада».
Но была проблема. Вот что говорит Джулия Льюсон, вице-президент Visual Studio в этом выпуске подкаста The Changelog:
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 за последние несколько лет превратилась в настоящий рай модулей с открытым исходным кодом. В этом отношении сейчас исторически беспрецедентное время.
Примечание: значок заката
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.
Примечание: значки печального упадка и «деньги, деньги, деньги»
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 в содержательном эссе под названием «Технический долг и поиск ветра», бывший инженер Fog Creek Тед Унангст сравнивает процесс с путешествием без карты:
В любом случае, объясняет Джейкоб Кралл, ещё один бывший разработчик Fog Creek, то решение принесло в жертву завтрашнюю ремонтопригодность ради сегодняшней скорости разработки. И к 2010 году стали приходит счета по этому долгу.
К тому времени FogBugz исполнилось уже десять лет: это был зрелый и стабильный продукт. В качестве побочного проекта Джоэл запустил Stack Overflow совместно с Джеффом Этвудом (очевидно, взорванная голова Джеффа к тому времени успела зажить).
FogBugz постепенно старел. Хотя рынок баг-трекеров оставался фрагментированным, на первый план стала выходить Jira от Atlassian, которая вышла через пару лет после FogBugz. Она стала выбором по умолчанию, особенно для крупных корпоративных пользователей.
На эту конкретную точку перегиба в истории FogBugz действительно интересно посмотреть со стороны. Как и у Basecamp, у них был прибыльный, зрелый продукт. Да, уже не такой модный и может над ним было не очень интересно работать. Хорошо это или плохо, но он вобрал в себя многие годы технологических изменений и новые идеи о том, как решать одну конкретную проблему: трекинг багов.
Конечно, был вариант Basecamp: с учётом всего опыта взять и переписать FogBugz с чистого листа. Предполагаю, эта идея не зашла слишком далеко, ведь мы помним: «чего никогда нельзя делать», «худшая стратегическая ошибка» и так далее, и тому подобное.
Недавно мне попалась на глаза статья 2009 года, которую Джоэл написал для Inc. Magazine. Его авторская колонка под заголовком «Означает ли медленный рост медленную смерть?» по тону совершенно не похожа на обычную самоуверенную напыщенность: она звучит интроспективно, неуверенно, наполнена сомнениями. Джоэл беспокоится о быстром росте Atlassian, рассуждает, есть ли на рынке место для нескольких игроков.
Он решает сделать две вещи. Во-первых, добавить все функции в FogBugz:
Во-вторых, создать корпоративный отдел продаж. Джоэл признаётся, что здесь он не силён, и находит неприятной данную задачу.
Не знаю, как сработали эти меры. Последний раз Джоэл упоминал FogBugz в своём блоге в мае 2010 года, вкратце анонсировав новую версию.
А произошло вот что:
Поэтому они разделились на две команды, каждая из которых делала прототип нового продукта. Победившая идея создана в духе канбан-доски — реальной офлайновой доски, которая часто используется в проектах по разработке программного обеспечения: обычно она выглядит как заметки, распределённые по столбцам на доске.
Джоэл представил эту программу как инструмент управления на более высоком уровне, чем FogBugz:
При создании Trello разработчики Fog Creek получили шанс использовать современные технологии:
Trello с самого начала поддерживал плагины, так что сторонние разработчики начали помогать:
Программисты, конечно, сразу поняли пользу Trello, Но в инструменте не было ничего специфического для разработки конкретно программного обеспечения. Джоэл описал Trello как полезный инструмент для «всего, где вы хотите совместно с другими людьми вести список списков». Вскоре Trello начали применять для организации всего подряд: от еженедельных обедов до свадеб и собачих приютов.
В то время как FogBugz был вертикальным продуктом — ориентированным на определённую рыночную нишу — Trello являлся горизонтальным продуктом, подходящим для чего угодно. Джоэл считает правильным «горизонтальное движение» 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 всегда заботилась не столько о баг-трекинге, сколько о расширении возможностей программистов — начиная со своих собственных:
С учётом этой «формулу» можно сделать логичный и ободряющий вывод: Fog Creek построил бизнес вокруг счастья разработчиков. Это отразилось как на продуктах компании, так и на её внутренней «операционной системе». Первый продукт, баг-трекер, послужил основой для запуска нового продукта, который решил аналогичную проблему более абстрактным способом.
Со слов Джоэла похоже, что история Trello — поиск не столько нового бизнеса, сколько возможностей поддержать мотивацию и вовлечённость разработчиков Fog Creek. Продукт стоимостью полмиллиарда долларов стал просто приятным побочным эффектом.
Впрочем, немного грустно, как всё закончилось для FogBugz. Не думаю, что разработчики Fog Creek были особо счастливы в последние дни перед продажей.
Ясно, что были проекты поважнее и покрупнее: Stack Overflow, Trello и Glitch — каждый в отдельности гораздо полезнее и ценнее, чем FogBugz; и одному человеку невозможно уследить за всем. Поэтому я не могу никого винить, в частности, за потерю интереса к FogBugz с 20-летней кодовой базой и сильной конкуренцией на рынке. Но лояльные пользователи хотя бы нашли хороший дом и не получили лекарство типа «закат»!
Однако сентиментальная часть меня предпочла бы более достойно «почтить наследие» всех причастных к созданию и использованию этого продукта за минувшие годы.
Примечание: значок «тайная операция»
Статья выросла больше, чем я предполагал, но не могу оставить в стороне эту историю. Держитесь, будет неожиданный поворот.
В начале 2000-х у Майка МакДермента была маленькая дизайнерская фирма. Он решил, что бухгалтерский софт слишком сложный, поэтому для выставления счетов использовал Word и Excel.
Всё нормально работало до одного случая:
Майк дизайнер, а не программист, но ему и двум соучредителям удалось собрать инструмент, достаточно хороший, чтобы несколько человек платили за его использование по $10 в месяц. Потребовалось почти четыре года, чтобы бизнес вышел из подвала родительского дома.
К 10-летнему юбилею программы (звучит знакомо?) Freshbooks стала прибыльной фирмой с более чем 10 миллионами пользователей и 300 сотрудниками.
Но имелась одна проблема. Ко времени, когда компании удалось нанять «настоящих» программистов, у них был миллион строк «кода основателя». Внешний аналитик рассмотрел кодовую базу и пришёл к выводу:
Что более важно, в существующем продукте невозможно было реализовать имеющиеся идеи:
МакДермент знаком с расхожим мнением, что нельзя переписывать систему с нуля:
Таким образом, они предприняли несколько попыток очистить беспорядок, не переписывая систему с нуля; но «заменить шины на ходу» оказалось невозможно.
МакДермента посетила идея втайне создать «конкурента» FreshBooks.
Он основал в Делавэре совершенно новую компанию под названием BillSpring. У неё был свой сайт, бренд и логотип. Стараясь не связывать две компании, он поручил внешнему юристу разработать для неё новые документы.
Команда разработчиков внедрила гибкие практики разработки по книге Джеффа Готельфа и Джоша Сейдена «Lean UX: проектирование отличных продуктов с гибкими командами»: скрам-команды и еженедельные итерации с обратной связью от реальных клиентов. МакДермент попросил их вести себя как стартап, а его воспринимать как венчурного инвестора:
Команде удалось выпустить MVP за несколько дней до дедлайна. Они купили ключевики AdWords для привлечения трафика, предложили пользователям бесплатные аккаунты на первый год. Вскоре появились клиенты — и начались быстрые циклы итерации настоящего продукта.
По окончании первого года BillSpring стала взимать плату. В какой-то момент новый продукт получил неожиданную оценку качества:
Вскоре они подняли завесу тайны и сообщили клиентам 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, то они согласны в одном: у легаси есть ценность.
Хорошая новость в том, что вам не нужно выбрасывать эту ценность, чтобы внедрять инновации.
«Исходный код словно заржавел!» — Джоэл Спольски
Почти два десятилетия назад Джоэл Спольски устроил разнос 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, то они согласны в одном: у легаси есть ценность.
Хорошая новость в том, что вам не нужно выбрасывать эту ценность, чтобы внедрять инновации.
Комментарии (41)
proton17
23.02.2019 23:07-1Интересно что дальше с Trello будет… Сейчас в Jira кабан доски полный писец. Кстати сейчас пользуем Yougile, весьма неплохая штука.
artemisia_borealis
23.02.2019 23:09+1Вы должны помнить, что долгое время Microsoft предлагала «всё или ничего». Если вы использовали Visual Studio, то обязательно работали в .NET, и наоборот.
Не должны. Что значит «обязательно работали в .NET»? Если студия для себя тянула .NET для своих целей, то это вовсе не значит "мы обязательно работали c .NET". Это как неявня зависимость функций. Тут важно, что можно было спокойно делать работу, например, в C++, совершенно не задаваясь вопросом про .NET и даже про то, что установлен ли он вообще на машине.
kekekeks
23.02.2019 23:35+2С VSCode всё, конечно, хорошо, если не учитывать тот факт, что это не IDE. Из аббревиатуры не хватает "Integrated". По сути это редактор, общающийся по LSP с независимыми языковыми серверами, каждый из которых является "вещью в себе". В итоге, если вам нужно из расширения к VSCode получить информацию по дотнетному солюшену, то брать её попросту неоткуда. В итоге невозможно сделать нормальный плагин для поддержки чего-то типа Nemerle, который бы работал с остальными дотнетопроектами. И подобных ограничений куча.
А так да, блокнот с поддержкой внешних плагинов автокомплита и подсветки синтаксиса хороший получился, годный.
HiTechSpoon
24.02.2019 08:35Была такая замечательная среда разработки CooCox CoIDE, для микроконтроллеров на основе архитектуры ARM. Основной её фишкой, на мой взгляд, был удаленный репозиторий с кодовой базой разбитой на категории и все это прямо из среды. Нужен код драйвера определенного экрана — держите, нужен код для управления микросхемой часов реального времени — пожалуйста. Не нашел что-то — пожалуйста, напиши и выложи в общий доступ в этот репозиторий. Кодовая база росла, популярность IDE тоже.
Но в один прекрасный день кто-то решил переписать продукт, в итоге старая база кода стала практически недоступной, поиск по новой базе был ужасен. Наверное можно было бы это исправить, но выпуск новых версий почему-то прекратился, форум продукта опустел, а потом и вовсе его заполонили боты с которыми никто уже не собирался бороться. А жаль, хороший был продукт с большой перспективой.
DrPass
24.02.2019 12:03+8По всем этим примерам можно сделать один вывод: неудачники останавливали разработку старого продукта и начинали создавать новый с нуля. Те же, кто стал успешным, создавали новый продукт параллельно со старым, не бросали поддержку и развитие предыдущего, и выкатывали новый, когда он уже был готов к употреблению и имел уникальные фичи.
Поэтому изначальный постулат Джоэля, в общем то, вполне верный. И если у вас нет средств на параллельное развитие двух веток продуктов, развивайте лучше старый.
Camill
24.02.2019 13:31Но не всё из Inbox перенесли в Gmail: например, люди настолько привыкли к «режиму паузы» (snoozing), что без него сейчас буквально физически страдают.
[...]
Думаю, для многих переход дался бы гораздо проще, если бы перед закрытием Inbox все его функции интегрировали в Gmail.
1. Inbox ещё не закрыли. Его обещают закрыть только в марте.
2. Функция Snooze уже есть в Gmail. На моём личном ящике она появилась в прошлом году, на корпоративном — где-то полтора месяца назад.
WeberWebber
24.02.2019 13:37+1Наверное, речь шла о продуктах, в которых много ноу-хау и которые писались ответственными разработчиками.
Многочисленные написанные быдлокодом проекты лучше переделывать, потому что любое большое изменение — это риск перехода из управляемого хаоса в неуправляемый. Или просто не соберёшь команду на старые технологии.DrPass
24.02.2019 16:10Многочисленные написанные быдлокодом проекты лучше переделывать, потому что любое большое изменение — это риск перехода из управляемого хаоса в неуправляемый.
Во всех таких случаях нужно сесть и думать, чем чреваты подобные переделки. Если вам в спину дышат конкуренты, а вы остановите развивать свой быдлокодовый проект, и выкатите новый красивый внутри и внешне, но более бедный по функциям, чем конкуренты на тот момент, ваш бизнес умрёт. Если ваш новый проект не будет иметь возможности лёгкой миграции со старого, и при этом не будет превосходить конкурентов, ваш бизнес умрёт. Если новый проект поломает сложившийся user experience, и при этом не будет превосходить конкурентов, ваш бизнес умрёт. В общем, нюансов много. Понятное дело, что в каждом кейсе могут быть свои нюансы, но в общем случае переделка с нуля даже самого паршивого говнопроекта, уже имеющего бизнес-историю — ходьба по краю. Тем более что почти всегда есть возможность постепенного улучшения того, что под капотом, без революций.WeberWebber
24.02.2019 17:02Чаще ситуация немного прозаичнее. Быдлокодеры доводят проект до стадии неконтролируемого хаоса, и пытаются впарить дальнейшую разработку аутсорсерам или экстернам.
Те, кто соглашается, льют потом горькие слёзы.
Мне, например, подсовывали код, где метод с невинным именем UpdateGridCell скрывал 4-значное число строк, читал и писал в БД и много чего другого делал. Причём так замысловато, что через три дня реальной головной боли я сдался.DrPass
24.02.2019 17:12Бывает и так, но я склоняюсь к тому, что подавляющее большинство более-менее успешных проектов всё-таки написаны не бездарями через полную задницу, а обычными программистами, с костылями, но терпимо.
WeberWebber
25.02.2019 06:39Я смотрю со своей колокольни, возможно потому что работаю в одной из стран ЕС, где исторически хороших разработчиков очень мало.
andreysmind
24.02.2019 17:44Я чаще видел, как проект превращался в адское создание, когда мамкины идеалисты начинали каждую неделю менять архитектуру на более красивую и правильную. А потом картинно уходили в закат сетуя на то что опять ничего не вышло.
WeberWebber
24.02.2019 21:00каждую неделю менять архитектуру на более красивую и правильную
«Вы знаете ноты» (с) Жванецкий
На упомянутых проектах нет архитектуры и моделирования. Кодится с первого дня — что вижу, то пишу.
klvov
24.02.2019 18:31Три дня! На то, чтобы с таким методом разобраться, может три месяца уйти легко, и то еще может не хватить.
WeberWebber
24.02.2019 20:58может три месяца уйти легко
Кто будет платить?klvov
24.02.2019 22:18Вот кто будет платить, пусть и принимает стратегическое решение — разбираемся с тем что есть, или переписываем с нуля.
teemour
24.02.2019 14:56Это все очень загадочно. Ибо вообще неясно кто в здравом уме может выбрать Jira этого лидера рынка.
nmrulin
24.02.2019 16:11Грань между глубоким рефакторингом и переписыванием с нуля зыбкая. Пусть у нас есть программа со 100 функциями. Потом допустим мы создали 10 классов и куда засунули видоизменившиеся 100 функций? Это ещё рефакторинг или переписывание с нуля. А если эти 100 функций по выдаваемому результату такие же, как старые 100 функций, но по коду у них совсем другой? А если у нас некоторые новые функции заменяют две старых? В любом случае, когда мы используем какие-то знания о старой логике программы, то это уже не «с нуля». А если не используем, то есть риск на те же грабли наступить.
Borz
24.02.2019 16:28отличие в том, что при рефакторинге вы можете выкладывать изменения инкрементально "почти" без потерь, а при "разработке с нуля" вам перед выкладкой надо как минимум догнать уже существующий функционал "старого" продукта и только потом можно начать выкладываться.
При этом конечный результат при рефакторинге может быть достигнут гораздо позже, чем при "с нуля", но он будет растянут во времени, при котором пользователи продолжали работать с вашим продуктом. Удобство пользователя важнее удобства разработчика
TheShock
24.02.2019 17:31+1Но это уже практически не имело значения, потому что за три года, что Netscape стоял на месте, Internet Explorer захватил всю оставшуюся долю рынка:
Ну вообще по графикам явно видно, что переписывание тут ни при чем. Уже два года Нетскейп серьезно терял позиции и начало переписывания никак не сказалось на тенденциях
NickFornit
24.02.2019 18:00Многие факторы, влияющие на целесообразность переписывания с нуля не рассмотрены (тут уж Гедель в помощь). К примеру, в вопросе о Нетскейп не учтен фактор войны браузеров. Многие вздохнули свободнее, когда не стало нужно поддерживать особенности парсинга Нетскейп, категорически не стекающегося с ИЕ буквально повсюду. Есть и многие другие причины, например, использование чужих модулей и фреймворков, система которых начинает трещать после слишком большого расхождения между ними или когда что-то перестало поддерживаться, или версии более не согласуются с текущим кодом сайта и т.п. Все в жизни бывает сложнее чем как бы очевидные правила типа “Никогда не следует делать так”.
Xaliuss
24.02.2019 18:51+1Хорошим (с точки зрения иллюстративности) примером переделок может послужить история мобильной винды. Переходы WM 6.5 — WP 7.0-7.5-8.0-8.1-WM 10 включают в себе 1 переписывание полностью, 1 почти целиком и ещё одно примерно наполовину. Совместимость при этом была такая себе. Это и привело к нынешней ситуации.
Майкрософт сейчас судя по слухам делает аналогичный процесс поддержания старой системы и написания нового ядра системы с нуля, Windows Core OS. Это больше походит на рецепт успеха из статьи выше, но предсказать пока результат затруднительно.
energizer888
24.02.2019 19:14Интересно, реально починить игровой движок Беседки не переписывая его заново и не порождая новых багов? С каждым следующим продуктом ситуация все удивительнее…
yayashitoya
24.02.2019 20:44+2Visual Studio — тяжеловесный продукт во всех смыслах
Ну не назвал бы платформу Electron идеалом легковесной платформы.
И вообще вся попытка притянуть VSCode к Visual Studio выглядит как «за уши».
Первое редактор (пусть и специализированный), а второе IDE.
И как на нем MS планировала делать бизнес, заменив VS на VSCode?
Разве что для имиджа фирмы полезен.DrPass
24.02.2019 22:01Первое редактор (пусть и специализированный), а второе IDE.
Ну чего? VSCode — абсолютно честная взрослая IDE. Там же есть всё — отладчики, средства автодополнения кода, интеграция с СУБД, инструменты сборки и т.д.
И как на нем MS планировала делать бизнес, заменив VS на VSCode?
Значительно расширяя круг разработчиков, которые затем будут пользоваться Azure и прочими сервисами MS, и потом продавать их вместе со своими решениями своим клиентам.
KanuTaH
24.02.2019 22:05+2Правда? Прям сразу в VS Code есть отладчик, например, для плюсового кода, без необходимости подключать всякие gdb/lldb? Даладна. А как же это:
Note: The C/C++ extension does not include a C++ compiler or debugger. You will need to install these tools or use those already installed on your computer.
? Ну и «средства автодополнения кода» там точно так же не будут адекватно работать без сторонних штук типа clang или gnu global. Блокнот — он и есть блокнот.DrPass
25.02.2019 00:05Правда? Прям сразу в VS Code есть отладчик, например, для плюсового кода, без необходимости подключать всякие gdb/lldb? Даладна. А как же это:
Скажите, а что, черта между IDE и блокнотом проходит в том, как плагины с инструментами разработки поставляются, в одном дистрибутиве, или из онлайновой репы? Если в дистрибутиве, то IDE, если надо через репозиторий доустанавливать, то блокнот?
Ни Visual Studio, ни даже Delphi образца 1997 года без подключаемых модулей не обладают возможностью ни автодополнения кода, ни отладки, ни визуальной разработки. Это всё — такие же плагины, как и в VS Code. Ну разве что от одного вендора, и в установочном скрипте прописаны.KanuTaH
25.02.2019 00:58Разница между IDE и блокнотом проходит по букве I — «integrated». В VS Code, в отличие от «взрослой» Visual Studio, нет этой самой буквы I. И плагины сами по себе там не помогают, они не работают без кучи сторонних toolchain'ов, которые надо устанавливать и настраивать вообще отдельно, и даже с этими toolchain'ами они работают с кучей ограничений, вон выше kekekeks привел хороший пример. Не дотягивает VS Code до «честной взрослой IDE», никак не дотягивает. Это как если бы я в Visual Studio поставил «поддержку C++», а она мне и говорит человеческим голосом — сорян, парень, cl.exe не входит в мою комплектацию, иди куда хочешь и ставь откуда хочешь. И какой-нибудь парсер для IntelliSense где-нибудь отковыряй, а то у меня будет только автодополнение в стиле Notepad++. И отладчик какой-нибудь заодно не забудь прихватить. Правда, как я со всем этим буду потом работать, и буду ли работать вообще — не могу обещать.
khim
25.02.2019 13:08В чужой монастырь со своим уставом не ходят. CLion, в котором всё очень прилично интегрировано и всякие рефакторинги в наличии — тоже требует сторонний toolchain и отладчик. Просто потому что так на Linux принято.
Flying
24.02.2019 21:50+2На всякий случай предлагаю вспомнить что Netscape 4 обладал движком со статическим рендером страниц т.е. после первоначальной загрузки страницы размеры / позиции элементов рассчитывались и уже не могли меняться. Для всякой динамики существовали такие вещи как
<layer>/<ilayer>. Поэтому вряд ли там вопрос решился бы рефакторингом, возможно переписывание было правильным решением.
Прекрасно помню своё "WOW!" когда я увидел первую бету NS6 которая динамически перестраивала layout страницы при ресайзе окна браузера, это выглядело настоящим волшебством :)
khim
24.02.2019 22:39С точки зрения «вау-фактора» это, конечно, крутно — а вот с точки зрения выживания компании — это было катастрофой. Так как было с самого начала заявлено, что "
<layer>— это тупик"… но ничего не было предложено взамен. То есть несколько лет разработчиков «кормили завтраками» то бишь демками).
Если бы, вместо этого, они всё это время развивали свою статическую модель — то не факт, что мы вообще получили бы тот ужас, который мы, в результате, получили.
Ибо всё это «волшебство» — оно, увы, небесплатно. Сильно небесплатно. А вот востребованность — весьма ограниченная. Даже сейчас. А уж в те времена, когда Netscape решилапобить горшкивсё переписать — и подавно.
KanuTaH
24.02.2019 22:02+1Оба продукта по-прежнему активно разрабатываются, и нет никаких признаков того, что Microsoft намерена закрыть Visual Studio.
А с чего бы им его вообще закрывать? Эти продукты вообще разного класса, Visual Studio — это мощнейшее IDE, включающее в себя весь инструментарий, необходимый для разработки приложений, от и до, а VS Code — это блокнот (да к тому же еще и на Электроне), стильно-модно-молодежно.WeberWebber
25.02.2019 12:22Кстати, сама Visual Studio в версии 2010 была в большой степени переписана на WPF.
KanuTaH
25.02.2019 15:09И при этом VS 2010 Express потребляла на моем тогдашнем Lenovo T420 примерно столько же ресурсов (по крайней мере в режиме дизайна и редактирования кода), сколько сейчас на этом же T420 потребляет Skype, написанный на Электроне. Electron is Cancer ©.
green_tree
24.02.2019 22:381) мы пользовались Basecamp2 по работе, потом они выкатили третью версию. Никто переходить не хотел, но нас заставили. Я не знаю подробностей, я простой тимлид, а кто в компании платил за это деньги сказали что мы не можем больше пользоваться второй версией на прежних условиях, надо переходить на третью. Без некоторых прежних функций стало очень неудобно, поэтому "конец интернета" настал достаточно быстро. Мы ушли в Трелло
2) на одном проекте пришлось работать с Freshbooks, я хз как оно со стороны бухгалтера (но раз миллионы пользователей и денег есть, видимо норм), но со стороны разработчика я бы сказал что лучше бы они остались в своём гараже и не вылезали оттуда =)
SvetaH
25.02.2019 18:03На строке «Fog Creek построил бизнес вокруг счастья разработчиков. Это отразилось как на продуктах компании, так и на её внутренней «операционной системе»» вспомнился мне Дин Бернетт.
Цитата:
«Как ни цинично звучит, но счастливые работники приносят больше прибыли.
Есть немало доказательств, что у счастливых работников производительность труда на 37 процентов выше. Если у вас работают сто человек, и все они счастливы, они могут выполнить работу 137 человек и при этом не нужно идти на дополнительные расходы.
Производительность труда несчастливых работников снижается на 10 процентов. Добавьте к этому, что у счастливых людей крепче здоровье, они реже жалуются, и вам станет ясно, что руководство компаний действительно хочет, чтобы работники были счастливы,
даже если видит в них всего лишь бездарных батраков»…
Рискую уехать в какую-нибудь метафизическую фигню, но похоже, что тут тоже есть над чем подумать…
denisshabr
26.02.2019 15:25>>Netscape Navigator, IPO на $3 млрд
Жесть конечно, даже по нынешним меркам. $3млрд за браузер! При стоимости за копию $49 планировалось продать его минимум 61 миллион раз, чтобы окупить компанию.
AOL вообще лидер по покупке за огромные деньги известных бизнесов, но по которым видно что скоро им хана, либо из-за снижения популярности, либо по вине AOL. Netscape, ICQ, Winamp. Такое ощущение, что во всех таких сделках была коррупционная составляющая со стороны AOL и возглавлявших его менеджеров.
История с МакДермента вообще показывает как он хотел нагнуть венчурных инвесторов и перетащить клиентов в новый продукт.
Stronix
Эм, они же просто взяли готовый Atom.
Mox
Пишут что monaco.
По «отзывчивости» студия оставляет Atom далеко позади, выглядит так, будто действительно разные редакторы там.
justboris
«взять Election» != «взять редактор Atom целиком»