Как говорится, единственный нормальный способ измерения кода — это количество WTF в минуту.

В более мягкой форме — это принцип наименьшего удивления. Даже Википедия говорит, что принцип хоть и формализован в ИТ, но использовался и раньше, да и люди находят ему применение в оффлайне. Одно из следствий принципа — существование шаблонов проектирования (чтобы архитектура была “привычной”). Другое — самодокументируемый код. Еще одна инкарнация этого принципа — анекдот про плохие интерфейсы: “Пользовательский интерфейс — как анекдот. Если его надо объяснять, то он плохой”.

Суть принципа очень проста: код, дизайн, UI, тесты и т.п. должны быть логичны, последовательны, соответствовать общепринятым (среди пользователей/команды) практикам и вообще не удивлять негативно. Например, строит проектировать код так, чтобы нельзя было написать “неправильно” или “неочевидно”. Если текущие инструменты не позволяют это сделать — обеспечить преодоление порога вхождения в контекст обучением, документацией и т.п., чтобы было хотя бы понятно, “как принято” писать. Другой пример: покрытие тестами не должно вызывать по причине “WTF, все сломал, а тесты еще зеленые”. А постановка задачи не должна вызывать “WTF, кому и нафиг это надо”. Даже на процессы это можно натянуть: новый сотрудник не должен в первые дни WTF’ить: что делать, как это работает, к кому идти, почему это так, кто это вообще такую дичь придумал, у кого это спросить и т.п.