Про comprehension debt

На прошлой неделе в посте про оргдизайн я вспоминал замечательную книгу Team Topologies. Одна из мыслей, которые мне очень запали в душу – это то, что зону ответственности команды надо проектировать с учетом ее ограниченной когнитивной емкости, а не просто закидывать в нее ответственность за все рядом лежащие компоненты.

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

Когнитивная нагрузка появляется от двух видов сложности:

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

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

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

Так мы и получаем comprehension debt – головы разработчиков уже перегружены, их емкости не хватает, чтобы вместить туда что-то новое, и знание о том, как работает продукт, постепенно ускользает. Спустя короткое время, команда уже не может безопасно менять свою систему – количество инцидентов растет, а способность их предсказать падает.

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

Еще про comprehension debt хорошо пишет у себя в канале Владимир Балун. Он руководил разработкой системы трейсинга с трафиком 11GB/s в Яндексе, поэтому набил руку на сложных системах, и знает, о чем говорит. Поэтому можете почитать его пост, а заодно подписаться на его канал, где он рассказывает о своем опыте программирования, разработке сложных высоконагруженных систем и просто делится своими мыслями о разработке.