Баланс качества   При разработке программного продукта хороший | )

Баланс качества
 
При разработке программного продукта хороший инженер стремится заложить идеальную архитектуру, написать безупречный код, достичь 100%-ое покрытие тестами, создать масштабируемое и отказоустойчивое решение. Это благие цели. Однако такой подход не всегда может позитивно сказыватся на конечном результате.
 
Сразу уточню, что все зависит от контекста. Следующие наблюдения применимы к молодым стартапам и заказной разработке с ограниченными сроками и бюджетом, но будут плохим советом для крупных Enterprise продуктов. 
 
При разработке больших энтерпрайз решений компания имеет много денег и времени. В таких условиях на первое место выходит качество разрабатываемого продукта. В стартапах и некоторых заказных проектах дела обстоят иначе. Там бизнес хочет быстро запуститься, валидировать идею и начать зарабатывать деньги.
 
Данный контекст непосредственно влияет на разработку. На начальном этапе имеет смысл отказаться от сложной архитектуры с кучей микросервисов, 100%-го покрытия тестами и пожертвовать лучшими практиками по написанию кода, что поможет сократить время выпуска продукта в продакшн. 
 
Главная цель на начальном этапе - сделать рабочую версию продукта, на который можно пустить трафик и получить первые результаты.
 
Будет ли это качественное решение? Нет.
Будет ли это масштабируемое и отказоустойчивое решение? Нет.
Будет ли этого достаточно на начале? Да.
 
Нужно держать в голове то, что клиент не заплатит вам за высокое покрытие тестами или красивый код. Он заплатит за рабочий продукт, который решает его проблемы, пусть даже он не будет идеальным на старте.
 
Много продуктов в начале создают из говна и палок. Когда идею провалидировали, появились первые клиенты и денежный поток, есть 2 варианта: все выбросить и сделать заново или привести до ума уже существующее решение. Какой вариант выбрать зависит от контекста и ресурсов.
 
Прелесть современной разработки в том, что так называемый Time to Market сейчас намного ниже чем 20-30 лет назад. 
 
Раньше разработчики создавали программный продукт несколько лет, после чего он записывался на дискеты или CD-диски (да, и такое было). Далее эти тиражи распространялись по всему миру, и если вдруг на этапе тестирования пропустили серьезный баг, исправить это было очень сложно.
 
Сейчас мы можем обновлять приложения хоть по 100 раз на день, поскольку запускаются они на наших серверах. Такой подход позволяет постоянно, итеративно улучшать продукт, параллельно обслуживая первых пользователей. 
 
Разработчики Basecamp запустили первую версию в продакшн без возможности приема платежей. Они знали, что после запуска у них есть 30 дней на решение этого вопроса. Первый год их приложение было развернуто на одном едином сервере. На данный момент этому приложению 15 лет и у них более 20 миллионов активных пользователей.
 
Плохой инженер делает как-нибудь, лишь бы работало.
Хороший инженер стремится сделать идеально, не вникая в бизнес.
Отличный инженер задает вопросы, пытается понять контекст и соблюдает баланс качества, исходя из ограниченности ресурсов.