Як пояснити, що розмір вибірки не впливає на тривалість проекту

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

Останній проект містив 250 000 елементів (рядків даних). Наступний проект буде містити лише 4000 предметів. Керівники проектів / ділові люди вважають, що проект повинен бути завершений на 1/10 час, оскільки це лише частка від розміру останнього проекту.

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

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

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

Дайте їм калькулятор і попросіть їх додати 1238783423 до 9858238483, час, який потрібно. потім попросіть їх додати 3423 до 8483 і скажіть, що ви очікуєте відповіді приблизно на 100000 разів швидше.

Ви могли б також пояснити кількість даних (можливо) ефекти проміжок часу програмний продукт буде приймати для запуску не на часі розробки.

Покладіть його на розмову менеджера.

Якщо ви створюєте машину для створення віджетів із 1 віджетом в секунду, неважливо, чи використовуєте ви її для виготовлення 100 віджетів або 10000 віджетів, сама машина потребує того ж часу, щоб створити.

Різниця полягає в часі виконання, а не в побудові часу.

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

Не використовуйте аналогію. Просто поясніть це.

• Для дуже невеликої кількості елементів (10?) Найдешевше конвертувати вручну. Не пишіть програму взагалі.
• Для невеликої кількості предметів (100?) Варто написати програму. Можливо, ви зможете заощадити, ігноруючи деякі перестановки даних, які теоретично можливі, але вони не відображаються на практиці в малому наборі даних. Або з'являються в такій малій кількості, що програма може їх відхилити, і їх можна перетворити вручну. Можна здійснити швидкий аналіз даних, щоб перевірити, чи справді кутові випадки відображаються в даних. Якщо вони не з’являються, їх можна ігнорувати.
• Після проходження цієї точки фактичний розмір даних не впливає. Вам потрібно написати серйозну програму, яка може обробляти будь-який можливий вклад. Програма може обробити 1000 предметів або 100 000. Просто бігати потрібно більше часу.

Освіта краще, ніж розмовляти :)

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

Ваш попередній проект включав (з того, що я отримую) копіювання даних з деякими модифікаціями на ньому.

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

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

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

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

Я думаю, що у вашому випадку менеджери просто грають у гру з оцінкою та намагаються змусити команду працювати швидше, вказуючи на різницю між 4000 та 250000 і сподіваючись на певну «провину». Я можу помилятися, але я це бачив раніше.

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

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

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

Це як якщо вам доведеться їхати в Мельбурн - але спочатку ви повинні побудувати машину.
Звичайно, їзда до Сіднея може бути швидшою - але побудова транспортного засобу займає стільки ж часу.
_{Гаразд, я дав тобі аналогію.}

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

Дані, які телефон передає, аналогічні даних, скопійованих вашою програмою.

Здається, ваші менеджери плутають робочий час із фактичним часом роботи програми. Але їх непорозуміння може бути різним. Вони можуть припустити, що там задіяно менше «полів». Не просто менше записів даних. Якщо є 100000 індивідуальних полів даних, це було б великим зусиллям розробки порівняно з лише 10 полями. Більше робота над картографуванням від системи до системи. У цьому випадку вони можуть бути правильними, але все-таки є постійні накладні витрати, і ви не можете просто розділити кількість полів, щоб отримати час.

Як мені подобається описувати, дані мають 2 розміри довжини та ширини. Довжина - це кількість записів, ширина - загальна кількість стовпців у всіх таблицях

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

тепер з 10 мільйонів і 10 тисяч найменший розмір все ще ширина. Тож саме ширина визначає, скільки часу потрібно, щоб зробити отвір.

Щоб заповнити метафору, якщо довжина менша, ви просто введете дані вручну

Я імпортую сотні клієнтських файлів щотижня.

Я знайшов одне, що для розробки імпорту даних малим файлам, як правило, потрібно більше часу, оскільки:

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

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

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

Багато керівників знайомі з накладними витратами на підготовку нового працівника, тому це може мати для них сенс.

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