DRY - ворог управління проектами програмного забезпечення?

Один з найбільш основних і широко прийнятих принципів розробки програмного забезпечення - DRY (не повторюйте себе). Зрозуміло також, що більшість програмних програм вимагають певного управління.

Тепер, які завдання легко управляти (оцінка, графік, контроль)? Правильні, повторювані завдання, саме ті завдання, яких слід уникати відповідно до DRY.

Отже, з точки зору управління проектами, чудово вирішити завдання, скопіювавши якийсь існуючий код 100 разів та зробивши невеликі адаптації до кожної копії, якщо потрібно. У всі часи ви точно знаєте, скільки роботи зробили і скільки залишилось. Всі менеджери будуть вас любити.

Якщо замість цього, ви застосуєте принцип DRY і намагаєтеся знайти абстракцію, яка більш-менш усуває дублюючий код, все інакше. Зазвичай можливостей багато, треба приймати рішення, робити дослідження, бути творчим. Ви можете запропонувати краще рішення за коротший час, але ви також можете провалитись. Здебільшого ви не можете реально сказати, скільки роботи залишилось. Ви найгірший кошмар керівника проекту.

Звичайно, я перебільшую, але дилема, очевидно, є. Мої запитання: Які критерії вирішувати, чи розробник перестарає сухий? Як ми можемо знайти хороший компроміс? Або є спосіб повністю подолати цю дилему, а не лише знайти компроміс?

Примітка. Це питання ґрунтується на тій же ідеї, що і в попередньому, Про кількість рутинної роботи з розробки програмного забезпечення та його вплив на оцінку , але, я думаю, це робить мою точку яснішою, тому шкода, що повторююсь :).

Ви, здається, припускаєте, що головна мета управління проектами - скласти точні оцінки. Це не так. Основна мета управління проектами така ж, як і для розробників: Надання цінності для власника продукту.

Продукт, що використовує безліч повільних ручних процесів, а не автоматизацію, теоретично може бути простіше оцінити (хоча я сумніваюся в цьому), але він не забезпечує співвідношення ціни та якості для замовника, тому це просто погане управління проектами. Дилеми немає.

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

Якби єдиною метою прем'єр-міністра було дати точні оцінки, то це було б легко. Просто занесіть оцінки до 10 разів, і дозвольте розробникам грати в ігри в іншому, якщо вони закінчать рано. Це насправді було б краще, ніж ваша пропозиція використовувати копій-вставити зайняті роботи, щоб зменшити час, оскільки гра в ігри не знизить ремонтопридатність продукту.

Але насправді власник продукту хоче, щоб корисні оцінки та якісний продукт були доставлені якомога швидше та дешевше. Це фактичні обмеження, до яких ПМ повинен буде орієнтуватися.

У будь-якому випадку я заперечую ваше припущення, що повторювана ручна робота більш передбачувана, ніж автоматизована. Весь досвід показує, що повторювана ручна робота більше схильна до помилок. А що робити, якщо помилка буде виявлена ​​в копіюваному коді? Раптом вартість виправлення помилки множиться на кількість повторень, через що невизначеність вибухає.

Ви маєте рацію - copy-paste працює чудово, і DRY не має жодного сенсу, коли ваше завдання - створити програму, для якої або скопійований шаблон, або копія не потрібно буде підтримувати або розвиватися в майбутньому. Коли ці два програмні компоненти мають зовсім інший життєвий цикл, то з'єднання їх між собою шляхом рефакторингу загального коду в загальну область, яка сама по собі знаходиться під серйозною розробкою, дійсно може мати непередбачувані наслідки для зусиль. З іншого боку, при копіюванні кодових розділів всередині однієї програми чи програмної системи всі ці частини, як правило, мають однаковий життєвий цикл. Нижче я проілюструю, що це означає DRY та управління проектами.

Серйозно, таких програм багато: наприклад, індустрія комп'ютерних ігор виробляє безліч програм, які потрібно підтримувати максимум протягом декількох місяців або року, а коли цей час закінчиться, скопіюйте копіювання. старий код з попередньої гри, в якому перевищено термін обслуговування, в нову базу коду гри ідеально чудово і може прискорити роботу.

На жаль, життєвий цикл більшості програм, з якими мені доводилося стикатися за останні роки, сильно відрізняється від цього. 98% вимог або запитів на виправлення помилок, які надійшли до мене, були запитами на змінудля існуючих програм. І щоразу, коли вам потрібно щось змінити в існуючому фрагменті програмного забезпечення, "управління проектами" або планування працює найкраще, коли ваші зусилля з тестування та налагодження досить низькі - це буде не в тому випадку, якщо ви щось зміните в одному місці, але завдяки копії -закріплена бізнес-логіка, яку ви легко забудете, вам потрібно змінити і десяток інших місць у кодовій базі. І навіть якщо вам вдасться знайти всі ці місця, час, щоб змінити їх усі (і протестувати зміни), напевно, набагато більше, як якщо б у вас є лише одне місце для зміни. Тож навіть ви можете зробити точну оцінку змін, оскільки витрати в десятки разів перевищують її, можна легко зіткнутися з бюджетом проекту.

TLDR - щоразу, коли ви розробляєте програму, де немає необхідності та не несе відповідальності за виправлення помилок та обслуговування оригіналу чи копії, сміливо копіюйте. Але якщо ви, ваша команда або ваша компанія несете відповідальність за них, застосовуйте DRY, коли зможете.

Приклад

Як додаток, дозвольте мені пояснити, що означає "виправлення помилок та технічне обслуговування", і як це призводить до непередбачуваності планування, особливо всередині одного продукту, на прикладі реального світу. Я дійсно бачив, як подібні речі відбуваються насправді, ймовірно, не зі 100 примірників, але проблеми можуть початися навіть тоді, коли у вас є лише один дублікат.

Завдання: створити 100 різних звітів для програми, кожен звіт виглядає дуже схожим, деякі відмінності в вимогах між звітами, якась інша логіка, але в цілому не багато відмінностей.

Розробник, який отримує це завдання, створює перше (скажімо, це займає 3 дні), після деяких змін або незначних виправлень помилок через QA та перевірку клієнтів закінчено, здається, він працює добре. Потім він почав створювати наступний звіт шляхом копіювання та внесення змін до всього, потім наступного, і для кожного нового звіту йому в середньому потрібно ~ 1 день. Дуже передбачувано, на перший погляд ...

Тепер, після того, як 100 звітів будуть "готові", програма переходить до реального виробництва, і виникають деякі проблеми, які були пропущені під час QA. Можливо, є проблеми з роботою, можливо, звіти регулярно виходять з ладу, можливо, інші речі не працюють за призначенням. Тепер, коли було застосовано принцип DRY, 90% цих проблем можна було вирішити, змінивши базу коду в одному місці. Але завдяки підходу копіювати-вставити проблему доводиться вирішувати 100 разів, а не один раз. І через зміни, які вже застосовуються з одного звіту в інший, розробник не може швидко скопіювати і вставити виправлення першого звіту в інший 99. Він повинен переглянути всі 100 звітів, прочитати їх, перекласти зміну на змінені повідомити, протестувати його та, можливо, налагодити кожен окремо. Для прем'єр-міністра це починає ставати дуже важко - він, звичайно, може зайняти час для "звичайного" виправлення помилок (скажімо, 3 години) і помножити це на 100, але насправді це, мабуть, неправильна оцінка, деякі з виправлень можуть бути легше зробити, ніж інші, іншим може бути складніше. І навіть якщо ця оцінка правильна, наявність налагодження коштує в 100 разів вище, ніж потрібно, коштуватиме вашій компанії чималі гроші.

Це станеться наступного разу, коли замовник попросить змінити колір емблеми своєї компанії у всіх цих звітах, щоб зробити розмір сторінки настроюваною або якоюсь іншою новою вимогою, яка впливає на всі звіти аналогічним чином. Тож якщо це трапиться, ви можете зробити оцінку витрат і розрахувати клієнта в 100 разів більше ціни, яку він повинен був би заплатити, коли код був ДУХИМ. Однак спробуйте це кілька разів, і тоді замовник скасує проект, оскільки він, ймовірно, не буде готовий платити ваші непомітні витрати на розвиток. І, можливо, в цей момент хтось задасть питання, чому це сталося, і вкаже пальцем на людину, яка прийняла рішення для цього програму копіювання-вставки.

Моя думка: коли ви виробляєте програмне забезпечення для інших, ви завжди принаймні на короткий проміжок часу несете відповідальність за те, щоб річ працювала, виправляла помилки, адаптувала програму під мінливі вимоги тощо. Навіть у проекті із зеленого поля ці деталі можуть швидко додати набагато більше, ніж спочатку заплановані зусилля по розробці. І особливо, коли весь ваш вставлений код копії знаходиться в одному продукті, період відповідальності є для всіх частин однаковим, що сильно відрізняється від ситуації, коли ви копіюєте вставлений старий код із мертвого проекту, якого більше немає. під активним обслуговуванням.

Отже, з точки зору управління проектами, чудово вирішити завдання, скопіювавши якийсь існуючий код 100 разів та зробивши невеликі адаптації до кожної копії, якщо потрібно. У всі часи ви точно знаєте, скільки роботи зробили і скільки залишилось. Всі менеджери будуть вас любити.

Твоє базове твердження невірно.

Що відрізняє програмне забезпечення від інших професій, це те, що ви робите щось нове щодня. Зрештою, жоден замовник не збирається платити вам за те, щоб побудувати щось, що хтось ще зробив. Керівникам проектів може подобатися передбачуваність, але їх начальникам подобається цінність . Якщо ви просто копіюєте вставлення коду з незначними варіаціями, ви не надаєте великої цінності для компанії.

Врешті-решт компанія зрозуміє, що може виконати ту саму роботу за частину часу, найнявши хорошого програміста. А якщо цього не зробити, їх конкуренти будуть.

Програмування «вирізати і вставити» врешті-решт призводить до відмови від програмного забезпечення. Я був підрядником системи замовлення послуг телефонного зв'язку у дуже великої телефонної компанії. Система була нарізана і наклеєна ad nauseum, оскільки все тестування було ручним, і вони не хотіли змінювати жодний робочий код. Найменше вдосконалення може призвести до появи нової копії сотень рядків коду. Спочатку заявка була написана для обробки рахунків до дванадцяти фізичних рядків. Звичайно, це обмеження було зроблено у сотнях локацій у коді. Приблизно через чотири роки бізнес запитав команду, що потрібно для обробки великих рахунків. Вони оцінили близько 18 мільйонів доларів. Тоді проект був переданий офшорній команді для мінімального обслуговування. Існуюча команда була звільнена.

Організації, які думають таким чином, стискаються компаніями з кращими технологіями.

Часто забута максима, яка застосовується тут, - правило 3 . Це стверджує, що нормально один раз скопіювати код, але крім цього його слід замінити загальним кодом.

3 може здатися довільним числом, але загальним сценарієм є те, коли дані та логіка дублюються в додатку та базі даних. Часто наводяться приклади, коли в базі даних є таблиця пошуку та клієнтська частина перерахування. Різниця в парадигмах не дозволяє це легко зберігати в одному місці, тому інформація часто з’являється в обох місцях.

Хоча приємно мати DRY-код, можуть бути випадки, коли ділова логіка диктує виняток, і тому вам доведеться створити два або більше біт коду з джерела, який був загальним раніше.

Отже - що робити? Код статусного кво (зрештою, YAGNI ). Хоча код слід писати для зручності модифікації, писати цілий пліт дзвіночків для чогось, що, можливо, не знадобиться, - це просто підживлення грошей.

У своєму запитанні ви перераховуєте лише три функції управління проектами - кошторис, графік та контроль. Управління проектами полягає у досягненні цілей у межах обмежень проекту. Методи, що застосовуються для досягнення цілей в рамках обмежень проекту, відрізняються для програмних проектів, ніж багато інших типів проектів. Наприклад, ви хочете, щоб виробничі процеси були повторюваними та добре зрозумілими. Однак розробка програмного забезпечення - це переважно робота зі знаннями- це не рутина і вимагає роздумів, а не дотримання жорстких інструкцій та процедур. Методи, які використовуються для ініціювання, планування, виконання, моніторингу та контролю та закриття програмного проекту, потребують обліку того типу робіт, який необхідно виконати над програмним проектом, зокрема, позапланової роботи, яку неможливо виконати. до конкретних інструкцій та процедур.

Я думаю, що інша проблема полягає в тому, що ви приймаєте DRY - концепцію, що стосується повторення інформації, і намагаєтесь застосувати її для управління завданнями. DRY просто говорить, що ви повинні мати лише одне авторитетне представлення інформації. Керівники проектів повинні це сприймати, оскільки це означає, що кожен буде знати, куди звернутися за інформацією, повідомлення про зміни буде легко, а зміни можна контролювати та керувати ними. DRY, через багаторазові шматочки, допомагає зменшити довгострокові витрати, допомагає підтримувати довгострокові графіки та покращує якість - три частини до Трикутника управління проектами . Потрібно інвестувати час і гроші, витрачені на те, щоб ефективно сушити речі, але завдання керівника проекту - це робити компроміси часу, вартості, графіку та якості.

Написання нового коду - лише невелика частина завдання

Ваша пропозиція полегшить оцінку частини спочатку написання нового коду. Однак для того, щоб реально запропонувати щось нове (незалежно від того, чи це абсолютно нова система, додавання функції або зміна функціональності) цього робити недостатньо, і це лише меншість роботи - оцінки, показані в літературі, говорять про те, що на практиці це частина - це щось на зразок 20% -40% від загальної роботи.

Тож більшість робіт (що включає адаптацію вашої початкової розробки до того, що було насправді потрібно, інтеграція, тестування, переписування, повторне тестування) не стає простішою для оцінки; навпаки, навмисне уникнення DRY просто зробило цю частину значно більшою, жорсткішою та з більш змінними оцінками - той помилка чи потреба в зміні, яка потребує зміни всіх клонованих частин, може не трапитися, але якщо це станеться, то ваші оцінки будуть абсолютно неправильні.

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

СУХА корисна, але вона також завищена. Деякі люди можуть зайняти це занадто далеко. Що багато розробників не усвідомлюють, це те, що щоразу, коли ви впроваджуєте DRY, щоб використовувати один і той же метод для двох (трохи) різних цілей, ви вводите своєрідну дуже тугу зв'язок між різними напрямами. Тепер кожного разу, коли ви змінюєте код для випадку першого використання, ви також повинні перевіряти, чи регресує він у випадку використання другого використання. Якщо це широко незалежні випадки використання, то дуже сумнівно, чи слід їх щільно з'єднувати - вони, мабуть, не повинні бути.

Надмірне використання DRY також може призвести до богоутворюючих методів, які складні для виправлення всіх різних випадків використання, до яких вони ставляться, коли, як правило, більш дрібні атомні методи, що повторюють якийсь код, були б набагато більш ретельними.

Однак я б припустив, що питання не є дійсно актуальним на рівні управління проектами. Керівник проекту насправді не захоче потурбуватися про цей рівень деталізації впровадження. Якщо вони є, це, ймовірно, мікроуправління. Дійсно ... як реалізуються речі, це більше відповідальність розробника та технічного керівництва. Управління проектами більше стосується того, що робиться і коли .

EDIT: За коментар, я погоджуюся, що, якщо полегшити оцінку часу розробки, уникаючи DRY, іноді можна зменшити кількість невизначеності. Але я вважаю, що це є несуттєвим питанням стосовно більш гострих питань (1), скільки часу до виконання вимог бізнесу, (2) яка технічна заборгованість береться на борт у процесі, та (3) ризики для загальної вартості право власності на зроблений архітектурний вибір - чи варто ДУХИТИ чи ні в багатьох випадках - це вибір дизайну, який повинен ґрунтуватися більше на ризику / винагороді цим факторам, ніж на тому, чи спрощує надання менеджерам проектів більш точної інформації .

Я думаю, ви неправильно розумієте СУХУ.

Давайте скористаємося прикладом:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

vs.

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

Замінивши клас B на C, ми дотримувались принципу DRY та зменшили дублювання коду. Але ми не збільшували невідомі або ризикували проект (якщо ви ніколи раніше не робили спадщини).

Я думаю, що ти маєш на увазі, коли говориш про DRY - це щось більше, як завдання дизайну. Тобто:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! Нова вимога! Деякі клієнти повинні мати можливість множити подвійні !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

vs.

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

Тут (припустимо, що це працює) ми розробили рішення, яке може вирішити як стару, так і нову вимогу, по суті намагаючись створити математичну модель проблеми реального життя або бізнес-правил. У реальному житті система, яку ми моделюємо, очевидно, буде набагато складнішою, наша модель її точно не підійде, а крайові випадки та несподівані результати потребують часу, щоб знайти та виправити.

Отже, чи варто брати в цьому випадку B або A версію 2?

• B буде більш конкретним до фактично вимаганої зміни з меншою кількістю побічних ефектів, і буде легше оцінити та зробити це швидше.

• Версія 2 призведе до менш загального коду вперед і стане більш елегантним рішенням

Ще раз кажу, що це зводиться до якості специфікації та вимог.

Якщо у нас є дуже чіткі специфікації, які охоплюють крайові регістри та зворотну сумісність, то ми можемо бути впевнені, що розуміємо систему досить добре, щоб переробляти модель, не створюючи помилок.

Якщо у нас є екстрений запит для одного клієнта, коли єдиною вимогою є зміна поведінки для цього клієнта без урахування загальної системи; то "вдосконалення" моделі за допомогою рефакторингу А несе істотний ризик. Обидва переривання інших клієнтів або перевиконання терміну через зайвий невідомий час, необхідний для розробки та тестування рішення.

Абзац за абзацом

Один з найбільш основних і широко прийнятих принципів розробки програмного забезпечення - DRY (не повторюйте себе). Зрозуміло також, що більшість програмних програм вимагають певного управління.

Правильно.

Тепер, які завдання легко управляти (оцінка, графік, контроль)? Правильні, повторювані завдання, саме ті завдання, яких слід уникати відповідно до DRY.

Завдання, що повторюються, повинні бути автоматизованими, обов'язковими . Вони нудні, схильні до помилок, коли їх роблять вручну.

Отже, з точки зору управління проектами, чудово вирішити завдання, скопіювавши якийсь існуючий код 100 разів та зробивши невеликі адаптації до кожної копії, якщо потрібно. У всі часи ви точно знаєте, скільки роботи зробили і скільки залишилось. Всі менеджери будуть вас любити.

Я думаю, ви можете змінити слово "адаптація" на "конфігурація". Подумайте, у вас є помилка в цьому фрагменті коду, який повинен бути скопійований. Помилка, яка з’являється в конкретних умовах. Якщо він не зафіксований у первинному джерелі, а він скопійований, місця буде виправлено дуже багато. Це може бути погано, але тоді хтось повинен:

• спочатку зафіксуйте код у вихідному джерелі;
• фіксуйте код у будь-якому іншому місці;
• переконайтесь, що це були всі місця. Коли ти скажеш, що це треба було зробити менеджеру, він, мабуть, когось ненавидів.

Якщо замість цього, ви застосуєте принцип DRY і намагаєтеся знайти абстракцію, яка більш-менш усуває дублюючий код, все інакше. Зазвичай можливостей багато, треба приймати рішення, робити дослідження, бути творчим. Ви можете запропонувати краще рішення за коротший час, але ви також можете провалитись. Здебільшого ви не можете реально сказати, скільки роботи залишилось. Ви найгірший кошмар керівника проекту.

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

Звичайно, я перебільшую, але дилема, очевидно, є. Мої запитання: Які критерії вирішувати, чи розробник перестарає сухий? Як ми можемо знайти хороший компроміс? Або є спосіб повністю подолати цю дилему, а не лише знайти компроміс?

Дуже багато людей вказали, що тут немає ніякої дилеми. Так і ні.

Якщо у вас є щось дуже експериментальне, що ніколи ще не робилося - немає ніякої дилеми. В іншому випадку, якщо у вас є щось, що потрібно зробити знову, як, наприклад, у новій системі бронювання, у вас вже є абстракції, просто залежить, що вам потрібно.

Я думаю, що дилема полягає в тому - чи варто реалізувати щось у функції, якщо це навряд чи буде просити. Реалізуйте щось за запитом. Нікому не потрібна величезна інфраструктура, яка не буде використана.

мова йде зовсім не про розробку для подальшого повторного використання або про принцип YAGNI. Йдеться про повторення коду в поточному робочому пакеті.

Це абсолютно стосується дизайну. Можливо, не повторне використання як таке, але все-таки дизайн.

Які критерії вирішувати, чи розробник перестарається із сухим?

Досвід та існуюче оточення / ситуація. З цією проблемою ви отримаєте сильне почуття Принципу Прадо, коли намагаєтеся досягти більшого рівня СУХОСТІ. Тоді раптом міркування керівництва починають грати. Час, цілі, замовник, довгострокове управління кодом (хтось сказав, технічна заборгованість ) тощо повідомить про ваш план нападу.

Як ми можемо знайти хороший компроміс?

А ... дизайн? Реконструкція - це дизайн, ну так і має бути. Область DRYing може легко розширитися як супер-нова з циклу, методу, класу (-ів). Був там зробив те. Але ти не можеш точно знати, поки не вивчиш проблему - це дизайн.

Як це не може бути проблемою дизайну? Ви повинні розглядати проблему ширше, ніж безпосередньо скопійований код. Це проектна діяльність, чи то наявний код, чи чистий аркуш; будь то "метод вилучення" або створення нових класів і модулів.

Епілог

... зазначене питання та його відповіді не охоплюють аспект управління проектом.

Типове управління, ігнорування дизайнерського часу. Ми б в ідеалі розробили надмірно зайву повторюваність до кодування. Натомість керівництво вважає, що розвиток (і виправлення помилок) є єдиною олімпійською подією - кодуванням - коли насправді це десятиборство. І вони вимірюють 1/1000 секунди, тому що вони думають, що це все аналог.

Якщо замість цього, ви застосуєте принцип DRY і намагаєтеся знайти абстракцію, яка більш-менш усуває дублюючий код, все інакше.

У мене був такий досвід: "Я витратив два дні на написання цього рядка (форми GUI), а дві години писав решту форми". Я маю на увазі, що я зайняв час для визначення багаторазових класів - DRY є природним побічним ефектом - рядок форми GUI та w / у тому, що деякі інші. Після налагодження вони використовувались індивідуально та композиційно, у всій формі, яка тепер кодується дуже швидко, а тестування було винятково швидким, незважаючи на складність розробки. І він пролетів через формальне тестування також з надзвичайно низьким рівнем помилок.

Здебільшого ви не можете реально сказати, скільки роботи залишилось. Ви найгірший кошмар керівника проекту.

Я теж не знав, але я вірив, що передні проектні зусилля окупляться. Ми всі це говоримо, але керівництво зокрема не вірить у це. Керівництво подумало б, що я накручуюсь. "Два дні, а ви навіть 2% цього ще не кодували!"

В одному випадку ми пристали до наших знарядь, коли керівництво сказало: "Ви витрачаєте занадто багато часу на дизайн, продовжуйте працювати". І співробітники кажуть, що "це занадто багато занять". Ну, набагато менш складний підпроект повинен був зайняти близько 1 місяця (я вважав, що це нормально здогадатися), але зайняло 5 місяців. 3 місяці цього було в тестуванні / фіксації, оскільки це був такий POS. "Але ми не встигли розробити!". Вони насправді це сказали.

Мої запитання: Які критерії вирішувати, чи розробник перестарає сухий? Як ми можемо знайти хороший компроміс? Або є спосіб повністю подолати цю дилему, а не лише знайти компроміс?

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