Один из важнейших принципов, который позволяет снизить темпы нарастания сложности, это принцип неразрастания кодовой базы без необходимости, который еще принято формулировать как YAGNI («You aren't gonna need it»).

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

Если же код пишется "на будущее", без четкого понимания зачем это делается, кто и как будет его использовать в обозримом будущем, то польза от него умозрительная, а вред самый настоящий. Я стараюсь такой код не писать сам и всячески препятствую его появлению в кодовой базе.

Тут, конечно, есть определенное лукавство 😳. Всегда есть вероятность, что придет потенциальный заказчик с каким-то запросом и, если нужного функционала у нас нет, то он уйдет к другим, а мы так и будем сидеть. Поэтому некоторые команды стараются наращивать функционал продуктов и платформ "на всякий случай", чтобы было что показать потенциальным клиентам. Ловушка в том, что, делая абстрактный функционал, вероятность сделать то, что будет востребовано реальными заказчиками, минимальна, как бы грустно ни было это осознавать. Даже если на первый взгляд покажется, что это прямо то что нужно, в реальности приходится долго и нудно все переделывать (а это гораздо сложнее, чем делать начисто)

Что же делать? Общего решения, как всегда нет, но есть несколько стратегий, которые позволяют хоть как-то двигаться, а не сидеть и ждать.
- Демонстрационная реализация. Совершенно не обязательно делать потенциальный функционал в production ready качестве, чтобы только его продемонстрировать и продать. Такая демонстрационная реализация имеет единственную цель - показать наличие функционала и найти потенциальных покупателей. После продажи его все равно придется переделывать, так давайте хотя бы не будем на него тратить сильно много времени и сил, не так жалко будет выкинуть. Так мы сильно улучшаем отношение польза/вред, но надо понимать, что в этом подходе мы разрабатываем не функционал продукта, а инструмент продаж, и требования (НФТ) к такого рода реализации будут другими.
- Развитие продукта вслед за продажами/проектами. Делать функционал не сразу, а по мере появления клиентов, которые будут им пользоваться, набивать шишки и развивать. Так мы при разработке приносим не только вред, но и пользу.

❗️P.S. Не надо думать, что "демонстрационная" реализация чем-то хуже чем "настоящая". Это не менее важная часть процесса разработки продукта, просто это немного другой продукт и у него другие пользователи.