Большинство разработчиков отлично справляются с написанием кода. Их главная слабость заключается в другом: они плохо решают, что именно заслуживает того, чтобы быть написанным. Именно здесь начинаются настоящие проблемы.
Вы можете ускорить релизы, внедрить модный фреймворк, распилить монолит на части, добавить еще одну очередь, дашборд или абстракцию. Но спустя полгода выясняется, что новой функцией никто не пользуется. Команда по уши в поддержке легаси, и все в замешательстве: инженерная производительность выросла, а реального прогресса для бизнеса нет.
Это парадокс эффективности: техническое совершенство превращается в пустую трату ресурсов, если оно направлено на решение неверной задачи.
Театр архитектуры и иллюзия прогресса
В ИТ-индустрии существует успокаивающая сказка: следуйте лучшим практикам, используйте современную архитектуру, внедряйте правильные инструменты и ритуалы — и бизнес-результаты появятся сами собой.
На практике исследования показывают более неприятную картину: большинство провалов в разработке — это не технические ошибки, а ошибки синхронизации (alignment failures).
Команды часто путают объем выполненной работы с конечным результатом. Они измеряют скорость (velocity) вместо ценности (value). Архитектура начинает восприниматься как доказательство того, что команда занимается «серьезной инженерией». Так рождается театр архитектуры.
Микросервисы — классический пример. Иногда они действительно необходимы. Но зачастую они превращают одну понятную проблему в 10 сервисов, 10 баз данных, 10 пайплайнов развертывания и 10 мест, где могут прятаться баги. Команда перестает решать проблемы клиентов, она платит «налог на отладку» и называет это прогрессом.
Ловушка разработки (The Build Trap)
Исследователи называют эту ситуацию «ловушкой разработки» — когда успех измеряется тем, что было выпущено, а не тем, что реально изменилось. Цифры говорят сами за себя:
- 80% разработанных функций используются редко или не используются вообще.
- 12% функций генерируют основной ежедневный трафик пользователей.
- От $50,000 до $500,000 — средняя стоимость разработки одной функции.
- $29.5 миллиардов в год — столько публичные облачные и SaaS-компании тратят впустую.
Много инженерной работы превращается в мертвый код. Этот код все равно нужно поддерживать, он увеличивает когнитивную нагрузку, создает зависимости и всплывает на код-ревью, вызывая у новичков резонный вопрос: «Зачем это вообще существует?».
Самая дорогая часть разработки — это не создание ненужного функционала. Это упущенная выгода (opportunity cost), которая может быть в 3–5 раз выше прямых затрат. Это все те действительно полезные вещи, которые вы не создали, пока полировали никому не нужную фичу.
Резюме-ориентированная разработка и бюджет сложности
Почему это продолжает происходить? Одна из причин — разработка ради резюме (resume-driven development).
Рынок щедро вознаграждает знание модных инструментов. Поэтому разработчики выбирают технологии, которые хорошо смотрятся в LinkedIn, а не те, что реально подходят для задачи. Разработчики не плохие — просто так работают стимулы рынка.
У каждого проекта есть свой бюджет сложности. Если вы потратите его на Rust, Kubernetes, векторные базы данных и новейший фронтенд-стек еще до того, как заработает базовая бизнес-логика, риски проекта взлетят до небес. Это не амбициозность. Это поджигание бюджета сложности и называние этого архитектурой.
Именно поэтому опытные (senior) инженеры часто выбирают «скучные» технологии:
- PostgreSQL
- Django
- Модульные монолиты
В них нет ничего гламурного, но они полезны. У зрелых инструментов известны сценарии отказов, лучше документация и меньше сюрпризов. Быть Senior-инженером — не значит избегать сложных инструментов из-за нехватки амбиций. Это значит тратить бюджет сложности только там, где это действительно приносит результат.
ИИ умножает ошибки
Искусственный интеллект не решает эту проблему, а лишь усиливает её. Когда написание кода становится быстрее и дешевле, команды могут выпускать еще больше плохо продуманного функционала.
Узкое место смещается от написания кода к принятию решений о том, что должно существовать. ИИ-агенты оптимизированы на завершение задачи, а не на понимание намерений. Если ваша цель ошибочна, ИИ просто поможет вам добраться до неправильного результата быстрее. Вы успешно автоматизируете собственные ошибки.
Как строить продукты, которые имеют значение
Ответ не в том, чтобы отказаться от технического совершенства. Ответ в том, чтобы правильно его направить.
1. На уровне кода: Стройте минимально функциональные вещи, которые создают ценность и рано выявляют риски. Не стройте идеальные платформы или переиспользуемые абстракции для будущего, которое может никогда не наступить.
2. На уровне архитектуры: Проектируйте под изменения. Модульный монолит — отличная стартовая точка. Он позволяет двигаться быстро и оставляет возможность разделить реальные предметные области позже, когда бизнес «испачкает» вашу идеальную UML-диаграмму и вы поймете, как система работает на самом деле.
3. На уровне продукта: Станьте продуктово-ориентированным инженером (product-minded engineer). Когда вас просят добавить новую фичу, не начинайте с вопроса «Как мы это построим?». Задайте три главных вопроса:
- Какую проблему это решает?
- Как мы узнаем, что это сработало?
- Чего нам будет стоить, если мы ошибаемся?
Именно за последний вопрос Senior-инженерам платят их деньги.
Кодинг ради результата означает принятие того факта, что техническое совершенство — это не цель, а инструмент. Лучшие инженеры — не те, кто пишет больше всего кода или внедряет новейшие архитектуры. Это те, кто связывает технические решения с человеческими потребностями, бизнес-результатами и долгосрочным здоровьем системы.
Иногда для этого нужно написать меньше кода. Иногда — выбрать скучную технологию. А иногда — убить свое собственное красивое решение, потому что оно перестало приносить пользу клиенту. Тратьте свой бюджет сложности с умом и никогда не путайте количество выпущенного софта с реальным влиянием на продукт.
На основе Most Developers Solve the Wrong Problems