Скорость разработки не бесплатна. За ускорение обычно приходится платить компромиссами: урезанным объёмом, дополнительными ресурсами, накопленным техническим долгом или повышенным риском.
Это не значит, что быстрое решение обязательно плохое. Иногда простой костыль — самый рациональный способ проверить гипотезу или успеть в важное окно. Проблема начинается, когда цена ускорения остаётся неизвестной, а временное решение незаметно становится постоянным.
Тогда система через некоторое время предъявляет счёт:
- не держит нагрузку или выпадает из SLA;
- падает на релизах;
- требует недели на добавление простой фичи;
- отдаёт значительную часть capacity команды багам.
Многих таких проблем можно избежать, если перед реализацией явно ответить на два вопроса: за счёт чего мы ускоряемся и когда собираемся оплатить принятый компромисс. Иногда после этого быстрое решение всё ещё остаётся лучшим — просто перестаёт притворяться бесплатным.
Эта проблема особенно заметна во время развитой кодогенерации через ИИ. Со стороны команда может выглядеть невероятно производительной: «мы тут за три недели всю систему переписали». Но количество написанного кода ничего не говорит о том, выдержит ли система нагрузку, можно ли её сопровождать и насколько дорого будет следующее изменение.
Высокая скорость сама по себе не признак плохой инженерии. Плохая инженерия начинается там, где команда не видит цену ускорения, не получает обратную связь от эксплуатации и не управляет последствиями своих решений.