Come spiegare che la dimensione del campione non influenza la lunghezza del progetto

Dì loro che è come costruire una nuova autostrada a quattro corsie in una parte remota del paese. Se quella strada viene utilizzata da 100 auto al giorno o 1000 auto al giorno, lo sforzo per creare la strada sarà all'incirca lo stesso.

Certo, se supporterà 1.000.000 auto al giorno, dovrai rendere la strada un po 'più robusta, ma a prescindere, dovrai abbattere gli stessi alberi, saltare attraverso le stesse montagne, livello la stessa quantità di sporco, e queste attività sono praticamente un costo fisso, non importa quante auto usano la strada.

Fornisci loro una calcolatrice e chiedi loro di aggiungere 1238783423 a 9858238483, tempo per quanto tempo ci vuole. quindi chiedi loro di aggiungere 3423 a 8483 e di 'loro che ti aspetti una risposta di circa 100.000 volte più veloce.

Potresti anche spiegare la quantità di dati (probabilmente) gli effetti del tempo che il software impiegherà a eseguire non il tempo di sviluppo.

Inseriscilo in manager.

Se costruisci una macchina per creare widget a 1 widget al secondo, non importa se lo usi per creare 100 widget o 10000 widget, la macchina stessa prende lo stesso tempo per costruire.

la differenza è in fase di esecuzione, non in fase di costruzione.

Tutte le classi di gestione lavorano su problemi come questo con ipotetiche fabbriche di widget.

Non usare un'analogia. Basta spiegarlo.

• Per un numero molto piccolo di articoli (10?) è più economico convertire manualmente. Non scrivere affatto un programma.
• Per un numero limitato di elementi (100?) vale la pena scrivere un programma. Potresti essere in grado di fare risparmi ignorando alcune permutazioni dei dati che sono teoricamente possibili, ma non appaiono in pratica nel set di dati di piccole dimensioni. Oppure appaiono in numeri così piccoli che il programma può rifiutarli e possono essere convertiti manualmente. È possibile eseguire analisi rapide sui dati per verificare se i casi angolari appaiono effettivamente nei dati. Se non appaiono, possono essere ignorati.
• Una volta superato questo punto, la dimensione effettiva dei dati non ha alcun impatto. Devi scrivere un programma serio in grado di gestire ogni possibile input. Il programma può gestire 1.000 articoli o 100.000. Ci vuole solo più tempo per essere eseguito.

L'istruzione è meglio che parlare:)

Non proprio un'analogia, ma credo ancora un buon modo per affrontare questo argomento: dimostra che c'è un difetto fatale in esso.

Il tuo progetto precedente includeva (da quello che ricevo) copia dei dati con alcune modifiche su di esso.

Se ho capito bene, è qualcosa che una squadra di, ad esempio, 100 contabili possono fare nel giro di pochi mesi. Allora perché hanno lanciato gli sviluppatori software al problema?

Poiché il software che hai creato non interessa se elaborerà 10 o 10 milioni di pezzi di dati (non esattamente, ma dubito che i tuoi manager si preoccupino della complessità di O(n) ). Pertanto, era probabilmente più economico, più veloce e più pulito (meno processo soggetto a errori).

Se sei più radicale, potresti anche suggerire che se non gli piace la velocità con cui lavora il team del software, possono sempre chiamare i ragionieri per fare il lavoro a mano.

Questo ha reso la vita dei tuoi manager molto più semplice mentre stavi sviluppando l'ultimo progetto, e ora, quando devono applicare la stessa logica per capire il prossimo pezzo di software, non importa se funzionerà il 10 milioni o 4 000 file, improvvisamente si dimenticano di esso.

Penso che nel tuo caso i gestori stiano semplicemente giocando a un gioco di stima e stiano cercando di costringere la squadra a lavorare più velocemente, sottolineando la differenza tra 4000 e 250000 e sperando in qualche "senso di colpa". Potrei sbagliarmi, ma l'ho già visto prima.

È un modo terribile di gestire un team di programmatori (in realtà qualsiasi tipo di team creativo) e non aiuta nessuno.

So che hai chiesto un'analogia, ma penso che sia la tecnica sbagliata.

Credo che, come altri hanno accennato di passaggio, è necessario sottolineare che le dimensioni dei dati influenzano tempo di esecuzione , non tempo di compilazione .
Quindi, scomposizione per loro - in realtà hai due sotto-progetti, che costruiscono e funzionano. Il progetto di costruzione dovrebbe (per la maggior parte) essere irrilevante di quanti dati verranno eseguiti, interessa solo i tipi di dati.
Per quanto riguarda il runtime - certo, possono tenerlo in considerazione in base alla dimensione dei dati (escludendo qualsiasi overhead fisso non banale).

È come se tu dovessi guidare a Melbourne - ma prima devi costruire la macchina.
Certo, guidare a Sydney potrebbe essere più veloce, ma costruire il veicolo richiede la stessa quantità di tempo.
_{Okay, ti ho dato un'analogia dopotutto.}

Forse un telefono? Il tuo cliente desidera un telefono personalizzato. Se effettua 0 chiamate al giorno o 100 chiamate al giorno, richiederebbe lo stesso tempo per creare il suo telefono.

I dati trasmessi da un telefono sono analoghi ai dati copiati dal programma.

I tuoi manager sembrano confondere dev-time con il tempo di esecuzione effettivo del programma. Ma il loro fraintendimento potrebbe essere diverso. Possono presumere che ci siano meno "campi" coinvolti. Non solo un numero inferiore di record di dati. Se ci sono 100000 campi di dati individuali, sarebbe uno sforzo enorme rispetto a solo 10 campi. Più lavoro di mappatura da sistema a sistema. In questo caso potrebbero essere corretti, ma c'è ancora un sovraccarico costante e non puoi semplicemente dividere per il numero di campi per ottenere il tempo.

Come mi piace descriverlo, i dati hanno 2 dimensioni, lunghezza e larghezza. La lunghezza è il numero di record, la larghezza è il numero totale di colonne su tutte le tabelle

Ora quando vuoi importare i dati è come ottenere un blocco attraverso un buco. È necessario creare un foro abbastanza grande per la dimensione più piccola, quindi eseguire il blocco attraverso

ora con 10 milioni e 10 mila la dimensione più piccola è ancora la larghezza. Quindi è la larghezza che decide quanto tempo ci vuole per fare il buco.

Per completare la metafora, ff è la lunghezza che è più piccola devi semplicemente digitare i dati in manualmente

Importo centinaia di file client ogni settimana.

Una cosa che ho trovato è che in genere i file di piccole dimensioni richiedono più tempo per sviluppare l'importazione dei dati perché:

• È meno probabile che seguano le regole (abbiamo un file standard strutture, non ho mai visto un piccolo cliente fornirci i dati nel formato standard che chiediamo ma i più grandi capiscono perché è così importante)
• Tendono ad avere più problemi di integrità dei dati, specialmente se lo sono proveniente da un file Excel anziché da un database (dove il grande i file tendono a venire) che aveva già costruito regole di integrità dei dati in
• È meno probabile che vengano fornite sempre nello stesso formato.

Abbiamo scoperto che risparmiamo molto tempo nello sviluppo costruendo un pacchetto SSIS padre genitore che ha un processo figlio standard e qualsiasi manipolazione necessaria per ottenere i dati nella forma dello standard può essere fatto nel genitore. In questo modo, diventa meno un problema di quanti record quando facciamo una stima, ma un problema di quanto vicino allo stanrdard è il file che stiamo ottenendo. Ora non riceviamo tanti reclami quando le cose più piccole impiegano più tempo a svilupparsi perché non si adattano allo standard.

Scrivere un programma è come assumere un nuovo dipendente. Devi insegnare loro dove trovare i dati, cosa farne e come darti i risultati. Devi tenerli d'occhio per un po 'per assicurarti che lo stiano facendo bene. Potrebbe essere necessario un po 'più di tempo per addestrarli se hanno un lavoro complicato / importante o se faranno una grande quantità di lavoro, ma ci vuole una notevole quantità di tempo, non importa quale.

Molti manager hanno familiarità con l'overhead coinvolto nella formazione di un nuovo dipendente, quindi questo potrebbe avere senso per loro.

(l'analogia si interrompe nella misura in cui il tuo nuovo dipendente è un robot superpotente che può portare a termine il lavoro in una quantità insignificante di tempo indipendentemente dal numero di record che passi a loro, ma spero che tu abbia fatto il tuo punto per allora. )