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

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

Что это значит? Это значит мы понимаем, что в любой системе есть ошибки, код и архитектура любой системы несовершенен, а функциональность всегда может быть дополнена. Но мы миримся с этим и относимся к этим недочётам как к необходимому злу, не давая им преодолеть некоторый порог, критичный для данного типа приложений. В данной статье, я коснусь концепции «достаточно хорошего» качества продукта, его кода и функциональности.
«пластилиновой» архитектурой и дампом подсознания в коде (об этом я ещё обязательно напишу) приобретает в этом контексте совершенно деструктивный смысл.

Мы теряем день за днём, оттачивая своё лётное мастерство, но лететь никуда так и не собираемся. Мы не можем остановиться и сказать: «Всё! Теперь — можно лететь», потому что всегда находится ещё пара-тройка не до конца освоенных лётных приёмов: бочка, петля Нестерова и другие (столь же не нужные в гражданской авиации) трюки.

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

Функциональность

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

Тут я, конечно же, не говорю о продуктах, основной изюм которых – позволить пользователю «сделать всё». Такие тоже бывают. Например, один наших продуктов (не буду конкретизировать, чтобы меня не объявили в рекламе ;) основан именно на этом преимуществе.

Посмотрите на Twitter. Его функциональность минимальна. Она достаточна для того, чтобы пользователи могли отправлять свои сообщения и читать чужие. Ни возможности добавлять в сообщения картинки («а как вообще можно без них», подумают многие), ни полноценной социальности (только Follow и reply), ничего лишнего 

Позднее вставка картинок всё-таки появилась, но сильно после того, как Twitter обрёл свою популярность.

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

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

Несколько строк в завершение

Итак, хотелось бы заметить очень важный момент: я ни в коем случае не призываю вас бросить писать аккуратно и начать «колбасить». Продукты, которые живут долго (и программисты, которые их поддерживают) вам этого никогда не простят. Я не призываю выпускать ПО с огромным количеством ошибок в критичных местах. Я не говорю, что богатая функциональность – это плохо.

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