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

Abbiamo grandi progetti aziendali che normalmente implicano la copia di dati da un database di origine a un database di destinazione e quindi la creazione di una serie di applicazioni aggiuntive che sincronizzano questi dati ecc.

L'ultimo progetto conteneva 250.000 articoli (righe di dati). Il prossimo progetto conterrà solo 4.000 articoli. I responsabili di progetto / uomini d'affari ritengono che il completamento del progetto dovrebbe essere 1/10 perché è solo una frazione delle dimensioni dell'ultimo progetto.

Qual è una buona analogia che posso usare per spiegare che la scrittura di codice per trasferire dati da un sistema a un altro richiede lo stesso importo indipendentemente dagli elementi numerici: la scrittura per 1 oggetto o per 100.000.000 richiederà all'incirca lo stesso tempo da una programmazione punto di vista.

Di 'loro che è come costruire una nuova autostrada a quattro corsie per 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à più o meno lo stesso.

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

Dai loro una calcolatrice e chiedi loro di aggiungere 1238783423 a 9858238483, tempo quanto tempo impiega. quindi chiedi loro di aggiungere 3423 a 8483 e di dire che ti aspetti che la risposta sia circa 100000 più veloce.

Potresti anche spiegare la quantità di dati (probabilmente) gli effetti del tempo impiegato dal software per eseguire non il tempo di sviluppo.

Mettilo in manager parla.

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

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

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

Non usare un'analogia. Spiegalo e basta.

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

L'istruzione è meglio che parlare giù :)

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

Il tuo progetto precedente includeva (da quello che ottengo) la copia dei dati con alcune modifiche.

Se ho capito bene, è qualcosa che un team di, diciamo, 100 contabili può fare in pochi mesi. Allora perché hanno lanciato problemi con gli sviluppatori software?

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

Se sei più radicale, potresti anche suggerire che se non gli piace la velocità con cui il team del software lavora, 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à su 10 milioni o 4 000 file, all'improvviso se ne dimenticano.

Penso che nel tuo caso i manager stiano semplicemente giocando a un gioco di stima e stanno cercando di forzare il team a lavorare più velocemente, sottolineando la differenza tra 4000 e 250000 e sperando in un certo "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 già detto, è necessario sottolineare che la dimensione dei dati influisce sul tempo di esecuzione , non sul tempo di costruzione .
Quindi, suddividilo per loro: in realtà hai due sottoprogetti, da costruire e da gestire. Il progetto di costruzione dovrebbe (per la maggior parte) essere irrilevante dalla quantità di dati su cui verrà eseguito, importa solo i tipi di dati.
Per quanto riguarda il runtime, certo, possono fattorizzarlo in base alla dimensione dei dati (escludendo qualsiasi overhead fisso non banale).

È come se dovessi guidare a Melbourne, ma prima devi costruire l'auto.
Certo, guidare a Sydney potrebbe essere più veloce, ma la costruzione del veicolo richiede lo stesso tempo.
_{Okay, dopo tutto ti ho dato un'analogia.}

Forse un telefono? Il tuo cliente desidera un telefono personalizzato. Se effettua 0 chiamate al giorno o 100 chiamate al giorno, occorrerebbe 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 reale di esecuzione del programma. Ma il loro malinteso potrebbe essere diverso. Possono presumere che ci siano meno "campi" coinvolti. Non solo un minor numero di record di dati. Se ci sono 100000 singoli campi di dati sarebbe un enorme sforzo di sviluppo rispetto a soli 10 campi. Più lavori di mappatura da sistema a sistema. In questo caso potrebbero effettivamente essere corretti, ma c'è ancora un certo overhead 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 in tutte le tabelle

Ora, quando vuoi importare dati, è come ottenere un blocco attraverso un buco. Devi fare un buco abbastanza grande per la dimensione più piccola, quindi trasportare il blocco

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, se è la lunghezza più piccola, digitare semplicemente i dati manualmente

Importa centinaia di file client ogni settimana.

Una cosa che ho scoperto è che i piccoli file richiedono generalmente più tempo per sviluppare l'importazione dei dati perché:

• È meno probabile che seguano le regole (abbiamo strutture di file standard, non ho mai visto un piccolo client fornirci i dati nel formato standard che chiediamo, ma quelli grandi capiscono perché è importante)
• Tendono ad avere più problemi di integrità dei dati, specialmente se provengono da un file Excel piuttosto che da un database (da cui i file di grandi dimensioni tendono a provenire) in cui erano già incorporate regole di integrità dei dati
• È meno probabile che vengano fornite sempre nello stesso formato.

Abbiamo scoperto che risparmiamo molto tempo nello sviluppo costruendo un pacchetto SSIS figlio principale che ha un processo figlio standard e qualsiasi manipolazione necessaria per ottenere i dati nella forma dello standard può essere eseguita nel genitore. In questo modo, diventa meno un problema di quanti record quando facciamo una stima ma un problema di quanto vicino allo standard sia il file che stiamo ottenendo. Ora non riceviamo tante lamentele 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 molto tempo, qualunque cosa accada.

Molti manager hanno familiarità con le spese generali legate alla formazione di un nuovo dipendente, quindi questo potrebbe avere senso per loro.

(l'analogia si interrompe nella misura in cui il nuovo dipendente è un robot superpotente che può svolgere il lavoro in un periodo di tempo insignificante, indipendentemente da quanti record gli passi, ma spero che tu abbia già espresso il tuo punto).