Как принять решение, когда все опции плохие?

Если жить в мире паттернов и лучших практик, то всегда можно натянуть сову на глобус и не переживать за выбор альтернатив. Но есть плохие новости – AI это умеет делать хорошо и без человека 😆

А вот при выборе решения прагматично архитектору часто приходится выбирать между "Клизмой и Сэндвичем" 😄 Надежное решение при этом очень дорогое. Дешевое решение очень хрупкое. Быстрое решение усложняет поддержку. А медленное решение никогда не одобрит бизнес.

В одной из моих прошлых компании у CEO была дилемма – как получить дешевую бизнес аналитику. Ему предлагали серьезные решения и его пугала финальная цена. В итоге он решил нанять джуна без комплексов и страхов, который на коленках дал ему бизнес аналитику. Джун понятия не имел как устроен мир дата архитектуры. Он покрыл весь код продукта генерацией событий, которые постоянно слались в вебморду для дашбордов. Дашборды мимикрировали под реальные как могли, у них не было исторических данных а были только реактивные события. Исходный код был загажен мусорными событиями, которые усложняли разработку продукта с каждым событием все сильнее и сильнее. То есть полученное решение формально было как бы очень простым и дешевым а по факту было безумно дорогим (постоянное ухудшение развития продукта) и нефункциональным.

Джун понял, что что-то не то и решил это исправить, засунув ручки в продовую БД (соединить дашборды и продовую БД продукта 🤣). Тут и подключился я, отрубив доступы к проду, и предложил альтернативу.

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

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

Как часто вам приходится выбирать наименее худшее решение?