Jak wyjaśnić, że wielkość próbki nie wpływa na długość projektu

Mamy projekty dużych przedsiębiorstw, które zwykle obejmują kopiowanie danych ze źródłowej bazy danych do docelowej bazy danych, a następnie konfigurowanie szeregu dodatkowych aplikacji, które synchronizują te dane itp.

Ostatni projekt zawierał 250 000 pozycji (wierszy danych). Następny projekt będzie zawierał jedynie 4000 pozycji. Kierownicy projektów / ludzie biznesu uważają, że czas realizacji projektu powinien wynosić 1/10, ponieważ jest to tylko ułamek wielkości ostatniego projektu.

Jaka jest dobra analogia, której mogę użyć, aby wyjaśnić, że pisanie kodu do przesyłania danych z jednego systemu do drugiego zajmuje tę samą ilość niezależnie od liczby elementów - napisanie go dla 1 elementu lub dla 100 000 000 zajmie mniej więcej tyle samo czasu z programu punkt widzenia.

Powiedz im, że to jak budowanie nowej czteropasmowej autostrady do odległej części kraju. Niezależnie od tego, czy z tej drogi korzysta 100 samochodów dziennie, czy 1000 samochodów dziennie, wysiłek stworzenia drogi będzie mniej więcej taki sam.

To prawda, że ​​jeśli ma obsługiwać 1 000 000 samochodów dziennie, musisz uczynić drogę nieco bardziej solidną, ale niezależnie od tego, będziesz musiał ścinać te same drzewa, przedzierać się przez te same góry, wyrównywać tę samą kwotę brudu, a te czynności są prawie stałe, bez względu na to, ile samochodów korzysta z drogi.

Daj im kalkulator i poproś, aby dodali 1238783423 do 9858238483, czyli ile czasu to zajmie. następnie poproś ich o dodanie 3423 do 8483 i powiedz, że oczekujesz odpowiedzi około 100000 razy szybciej.

Warto również wyjaśnić ilość danych (prawdopodobnie) Skutki czas oprogramowanie odbędzie się uruchomić nie czas rozwoju.

Przekaż to kierownikowi.

Jeśli zbudujesz maszynę do tworzenia widżetów z szybkością 1 widżetu na sekundę, nie ma znaczenia, czy użyjesz jej do wykonania 100 widgetów, czy 10000 widgetów, zbudowanie samego komputera zajmuje tyle samo czasu.

różnica dotyczy czasu wykonywania, a nie czasu kompilacji.

Wszystkie klasy zarządzania pracują nad takim problemem z hipotetycznymi fabrykami widgetów.

Nie używaj analogii. Po prostu wyjaśnij to.

• W przypadku bardzo małej liczby elementów (10?) Najtańsze jest ręczne przeliczanie. W ogóle nie pisz programu.
• W przypadku niewielkiej liczby pozycji (100?) Warto napisać program. Możesz być w stanie zaoszczędzić, ignorując niektóre permutacje danych, które są teoretycznie możliwe, ale nie pojawiają się w praktyce w małym zestawie danych. Lub pojawiają się w tak małych liczbach, że program może je odrzucić i można je przekonwertować ręcznie. Można przeprowadzić szybkie analizy danych, aby sprawdzić, czy przypadki narożne rzeczywiście występują w danych. Jeśli się nie pojawią, można je zignorować.
• Po przekroczeniu tego punktu rzeczywisty rozmiar danych nie ma wpływu. Musisz napisać poważny program, który poradzi sobie z każdym możliwym wejściem. Program może obsłużyć 1000 pozycji lub 100 000. Uruchomienie zajmuje tylko dłużej.

Edukacja jest lepsza niż gadanie :)

Nie do końca analogia, ale nadal uważam, że dobrym sposobem jest poradzenie sobie z tym argumentem: wykazać, że ma w sobie fatalną wadę.

Twój poprzedni projekt obejmował (z tego, co otrzymuję) kopiowanie danych z pewnymi modyfikacjami.

Jeśli mam rację, zespół, powiedzmy, 100 księgowych może zrobić w ciągu kilku miesięcy. Dlaczego więc rzuciły na programistów problem?

Ponieważ stworzone przez ciebie oprogramowanie nie ma znaczenia, czy będzie przetwarzać 10 czy 10 milionów danych (nie do końca, ale wątpię, by Twoi menedżerowie dbali o O(n)złożoność). Tak więc prawdopodobnie był tańszy, szybszy i czystszy (proces mniej podatny na błędy).

Jeśli jesteś bardziej radykalny, możesz nawet zasugerować, że jeśli nie podoba im się szybkość działania zespołu oprogramowania, zawsze mogą wezwać księgowych do wykonania pracy ręcznie.

Ułatwiło to życie menedżerom podczas opracowywania ostatniego projektu, a teraz, kiedy muszą oni zastosować tę samą logikę, aby dowiedzieć się, czy następne oprogramowanie nie ma znaczenia, czy będzie działać na 10 milionach, czy na 4 000 rzędów, nagle o tym zapominają.

Myślę, że w twoim przypadku menedżerowie po prostu grają w grę szacunkową i próbują zmusić zespół do szybszej pracy, wskazując różnicę między 4000 a 250000 i licząc na „winę”. Mogę się mylić, ale widziałem to już wcześniej.

To okropny sposób zarządzania zespołem programistów (właściwie każdego rodzaju zespołem kreatywnym) i nikomu nie pomaga.

Wiem, że poprosiłeś o analogię, ale myślę, że to zła technika.

Uważam, jak wspomnieli inni, że należy podkreślić, że rozmiar danych wpływa na czas wykonywania , a nie na czas kompilacji .
Więc podzielcie to dla nich - faktycznie macie dwa podprojekty, budujący i realizujący. Projekt budynku powinien (w przeważającej części) być nieistotny dla ilości danych, na których będzie on działał, ma to znaczenie tylko dla typów danych.
Jeśli chodzi o środowisko uruchomieniowe - na pewno mogą to uwzględniać zgodnie z rozmiarem danych (z wyłączeniem wszelkich nietrywialnych stałych kosztów ogólnych).

To tak, jakbyś musiał jechać do Melbourne - ale najpierw musisz zbudować samochód.
Oczywiście, podróż do Sydney może być szybsza - ale budowa pojazdu zajmuje tyle samo czasu.
_{Dobra, w końcu podałem ci analogię.}

Może telefon? Twój klient chce telefonu na zamówienie. Jeśli wykona 0 połączeń dziennie lub 100 połączeń dziennie, utworzenie jego telefonu zajęłoby tyle samo czasu.

Dane przesyłane przez telefon są analogiczne do danych kopiowanych przez Twój program.

Wygląda na to, że Twoi menedżerowie mylą czas programowania z rzeczywistym czasem działania programu. Ale ich nieporozumienie może być inne. Mogą założyć, że w grę wchodzi mniej „pól”. Nie tylko mniej rekordów danych. Jeśli istnieje 100 000 pojedynczych pól danych, byłby to ogromny wysiłek twórczy w porównaniu z tylko 10 polami. Więcej prac związanych z mapowaniem z systemu na system. W tym przypadku mogą one być rzeczywiście poprawne, ale wciąż istnieje pewien stały narzut i nie można po prostu podzielić liczby pól, aby uzyskać czas.

Jak lubię to opisywać, dane mają 2 wymiary długości i szerokości. Długość to liczba rekordów, szerokość to całkowita liczba kolumn we wszystkich tabelach

Teraz, gdy chcesz zaimportować dane, to jak przejście bloku przez otwór. Musisz zrobić dziurę wystarczająco dużą dla najmniejszego wymiaru, a następnie przenieść blok

teraz przy 10 milionach i 10 tysiącach najmniejszym wymiarem jest wciąż szerokość. Tak więc szerokość decyduje o tym, ile czasu zajmuje wykonanie otworu.

Aby uzupełnić metaforę, jeśli długość jest mniejsza, wystarczy wpisać dane ręcznie

Co tydzień importuję setki plików klienta.

Jedną z rzeczy, które znalazłem, jest to, że małe pliki zwykle zajmują więcej czasu, aby opracować import danych, ponieważ:

• Rzadziej przestrzegają zasad (mamy standardowe struktury plików, nigdy nie widziałem, aby mały klient przekazywał nam dane w standardowym formacie, o który prosimy, ale duże rozumieją, dlaczego jest to ważne)
• Zwykle mają więcej problemów z integralnością danych, zwłaszcza jeśli pochodzą z pliku Excela, a nie z bazy danych (skąd pochodzą duże pliki), która ma już wbudowane reguły integralności danych
• Za każdym razem rzadziej będą dostarczane w tym samym formacie.

Odkryliśmy, że oszczędzamy dużo czasu na programowaniu, budując nadrzędny pakiet SSIS nadrzędny, który ma standardowy proces potomny, a wszelkie niezbędne manipulacje, aby uzyskać dane w postaci standardu, można wykonać u rodzica. W ten sposób staje się mniej kwestia liczby rekordów, gdy dokonujemy oszacowania, ale kwestia tego, jak blisko standardu jest plik, który otrzymujemy. Nie otrzymujemy teraz tylu skarg, gdy opracowywanie mniejszych rzeczy zajmuje więcej czasu, ponieważ nie pasują one do standardu.

Pisanie programu przypomina zatrudnienie nowego pracownika. Musisz nauczyć ich, jak znaleźć dane, co z nimi zrobić i jak dać wyniki. Musisz przez chwilę ich pilnować, aby upewnić się, że robią to dobrze. Przeszkolenie ich może zająć trochę dłużej, jeśli mają skomplikowaną / ważną pracę lub jeśli wykonają bardzo dużo pracy, ale zajmuje to dużo czasu, bez względu na wszystko.

Wielu menedżerów zna koszty ogólne związane ze szkoleniem nowego pracownika, więc może to mieć dla nich sens.

(analogia załamuje się, o ile twój nowy pracownik jest supermocnym robotem, który może wykonać pracę w trywialnym czasie, bez względu na to, ile rekordów na nią rzucisz, ale mam nadzieję, że do tego czasu masz rację.)