Good Enough Code, ч.3 — Diminishing returns
[ч.2] | [ч.4]

Що найбільше заважає нам у розробці? Звісно, ми самі. Але сьогодні мова про більш конкретного ворога — diminishing returns.

До прикладу, вам до рук потрапляє якийсь модуль, який вам за першу ітерацію вдається оптимізувати, припустимо, на 50% — з 400мс до 200мс. Наступні дві ітерації дають ще 10% — з 200мс до 180, потім ще 10%, вже до 162. Але зусиль — утричі більше.

Вигода, очевидно, занадто мала, тенденція ж — очевидна. А якщо рахувати загальну вигоду, то від початкового стану ви виграли за першу ітерацію цілих 50%, а за усі три ітерації разом — 59,5%. Тобто в результаті додаткових зусиль ви не виграли й десяти відсотків.

Звісно, цей приклад досить спрощений, однак чудово ілюструє принцип diminishing returns. Ви вкладаєте усе більше часу, отримуючи усе менше реального результату. Ба більше, на практиці часто якраз ось ці додаткові зусилля привносять ще й нестабільність до системи, збільшуючи її схильність до помилок та вартість подальшої підтримки.

Як зловити себе? Ви витрачаєте непомірно більше часу на удосконалення рішення, аніж на саме рішення. Більш явна ознака — команда не розуміє доцільність вашого затягування (це вже навіть не дзвіночок, це великодній дзвін). Або ж ви просто не можете зупинитись і починаєте полірувати заради самого полірування — впадаючи в азарт, попри мізерний ефект.

Ось тут вперше й прозвучить головна ідея усієї концепції Good Enough Code:
"Час від часу випускайте на волю свого внутрішнього Януковича, який казатиме вам “АСТАНАВІТЄСЬ“".

Вкрай важливо розуміти, коли ваше пакращення уже не буде пакращенням. Якщо ви намагаєтесь досягти прискорення вашого алгоритму на 2мс у фінансовому застосунку — це абсолютно виправдано. Там це може означати втрачені мільйони. Але якщо ви третій тиждень поліруєте форму на п’ять полів, щоб кнопка Submit спрацьовувала на 20мс швидше — це марно згаяний час. Користувач не помітить різниці.

Оцінюючи diminishing returns надзвичайно важливо брати до уваги не лише конкретні цифри, метрики й показники, а й доцільність покращень. Доречність витрати часу. Не кожне покращення — виправдане. Однак кожна зайва складність має ціну.

Не все потребує покращення. Я знаю, цю думку складно прийняти. Ще раз: не все потребує покращення. Але усе потребує стабільности. Про що ми й поговоримо наступного разу.

Якщо вам дуже сподобався цей допис, звичайно.

@babichdev

Дуже цікаво дізнатися вашу думку щодо diminishing returns — згодні, не згодні, вважаєте це проблемою чи вигадкою? Ласкаво прошу до дискусії!

#good_enough_code