KISS в ахритектуре Возьмем две продуктовые компании. Компания А разрабатывает продукт на стеке Java, PostgreSQL, Kafka, Redis, ElasticSearch и CI/CD наборе. Для упрощения предположим что у технологий одинаковая сложность равная единице. Итак, суммарная технологическая сложность продукта компании А - 6. Предположим средний сотрудник обладает 3 глубокими релевантными скилами по технологиям. Наняв 10 сотрудников получим среднее покрытие в виде 5 инженеров на технологию. Разумеется, Java и СУБД знает почти каждый инженер, а остальные технологии по остаточному принципу, но как минимум по 1-2 человека на технологию. Компания B - разрабатывает аналогичный продукт на стеке Java, PostgreSQL и CI/CD наборе. Наняв 10 аналогичных сотрудников мы получим среднее покрытие в виде 10 человек на технологию. Следствием будет более высокий BusFactor и меньшие риски от ухода отдельных людей. Пример, конечно, грубый. Но на личном опыте видел, как необоснованно внедренные технологии требовали буквально выделенных людей для поддержки этих технологий. Либо общий скилл инженеров был недостаточен и дополнительные технологии не добавляли никаких бонусов от использования. Дополнительные технологии так же влияют на сложность CI/CD процесса и стоимость инфраструктуры. Не говоря уж о том, что они добавляют новые точки отказа в продукт. Этими примерами не пытаюсь призвать отказываться от технологий которые “на слуху”, но хочу обратить внимание что многие инженеры, кажется, очень легко соглашаются на внедрение тех или иных технологий, восхищаясь производительностью и ништяками, и слишком мало задумываясь о негативном влиянии того, с чем хотят "поиграться".