Недавно я задумался: ПО часто выходит из под контроля и обрастает фичами при экспериментах, но при этом в жизненном цикле эксперимента нет “выпилить при недостаточных результатах”. В Bloatware нет ничего нового, корпоративное ПО особенно ему подвержено. Но ведь простота - прекрасна!

Нужно ли управлять простотой?

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

Чья это задача?

Всех = ничья, если это не прекрасный идеальный мир.
Продакта - смехотворно, они напротив, ~~развивают~~ усложняют проект.
Техлида - до этого не добираются, погрузившись в технологичность - внедрение инфраструктурных плюшек, усреднение стека по компании, стандартизация, повышение надёжности итд.
Разработчиков - обычно им не хватает аргументации за “а давайте выпилим прекрасно работающую фичу, в разработку которой вбухали 35 человекодней, она не такая уж популярная и в последний раз её использовали 7 месяцев назад”.

В прекрасном идеальном мире техлид и продакт осознают ценность простоты, договариваются и стремятся сохранять проект простым:

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

Как измерить простоту?

Я ни разу не видел, чтобы собирали исторические данные о динамике усложнения проекта. Что можно собирать?

“Физические” единицы - число строк кода, файлов, директорий и их глубину. Классов, функций и глубину иерархий наследования. Число автотестов. По отдельности эти метрики бессмысленны, но все вместе должны показывать динамику.
“Логические” единицы - число API-эндпоинтов, число методов в каждом эндпоинте. Количество генерируемых типов событий для асинхронных интеграций, число внутренних асинхронных типов событий и число подписок на события других систем. Число систем, с которыми интегрируется наша система. Число периодических задач.

Что с этими данными делать

Хз. Бегать, орать, в случае если проект только ~~обрастает жирком~~ развивается. Наверное было бы неплохо сделать для себя алерты при достижении пороговых значений. Для начала, зафиксировать текущие значения и при 30% приросте сложности брать в работу задачу “осмотреть проект и понять, что в нём бесполезно и нужно удалить”, либо взять отложенные на потом, потому что то самое “потом” - наступило. Затем снова фиксировать текущий уровень сложности. Повторять до бесконечности.

Удерживать проект ниже определённого уровня сложности не выйдет - потребности бизнеса меняются, расширяются - и это нормально. Просто современному миру разработки ПО нужен дополнительный повод вспомнить: KEEP IT SIMPLE STUPID.