Письмо 7. Лучше хуже, но быстрее. Иногда
Существует известная и старая статья под названием «The rise of worse is better» («Рост худшего как лучшего»). В ней описаны удивительные способы, которыми происходят технологические нововведения. Основное внимание уделено сравнению простоты с полнотой и правильностью, где доказывается, что что-то простое, но неполное (и иногда даже неправильное) часто оказывается успешнее «лучшего», но более сложного решения.
Во многом это связано со скоростью. Чтобы сделать что-то совершенно правильным, требуется время, и программистам также нужно время, чтобы освоить более сложные вещи. Простое решение, которое работает сегодня и может иметь проблемы, которые придется решать завтра, часто оказывается выигрышным.
Технологическая индустрия развивается циклично. Сейчас мы находимся на этапе, когда появляются и внедряются новые шаблоны и стандарты. Это «дисруптивная» фаза, отличающаяся от привычной нам «постепенной» фазы. В этот период скорость приобретает особую важность. Часто победителем становится тот, кто первым выходит с новой парадигмой программирования, моделью приложения или бизнес-шаблоном, просто потому, что он начал первым. Иногда эта разница исчисляется всего несколькими неделями.
Это особенно актуально для решений, которые обладают сетевым эффектом. Сети по своей природе имеют экспоненциальный рост. Как только начинается сетевой эффект, даже в небольших масштабах, становится почти невозможно для других его прервать, если только они не совершат мгновенный скачок с использованием другого подхода.
Хороший способ понять это — подумать, что можно будет исправить позже, а что нет. Некоторые вещи (например, мелкие синтаксические ошибки) можно исправить позже, а другие (например, инерцию экосистемы) нельзя. В этот момент крайне важно не тратить время на устранение проблем, которые можно будет решить позже, если это приводит к возникновению нерешаемых проблем.
Для крупных компаний это требует значительного изменения мышления. В крупных и зрелых бизнесах мы привыкли действовать осторожно, тщательно и ценить правильность выше скорости. Это верный подход в период постепенного развития. Но сейчас мы живем в период, когда скорость принятия решений и последующая доработка более ценны и важны. Важно также избегать внутренней борьбы — там, где возможен сетевой эффект (предпочтения разработчиков, экосистемы, пользовательские данные), крайне опасно тратить время на его разобщение и «дать лучшей команде победить». Сейчас абсолютно верно, что хорошее решение, принятое сегодня, будет лучше, чем отличное решение через месяц, потому что кто-то другой уже опередит нас.