Про переписывание с нуля

Решения, которые вы приняли сегодня, определят решения, которые вы примите завтра.

В контексте переписывания задачи с нуля, я вспомнаю про Джоэла Спольски. У Джоэла есть замечательная заметка про то, почему переписывание софта с нуля - это зло.

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

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

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

Взгляд бизнеса на переписывание с нуля

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

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

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

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

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

Взгляд разработчика на развитие проекта

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

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

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

Чем дольше существует проект, чем больше фич создано и чем больше собрана пользовательская база, тем сложнее менять решения, которые были приняты изначально. Возникает простая причинно-следственная связь: "решения, которые вы приняли сегодня, определят решения, которые вы примите завтра".

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

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

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

Переписыване проекта

И бизнес, и программисты возлагают большие надежды на переписывание проекта - это попытка отложить проблемы на потом.

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

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

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

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

Выводы

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

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

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

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