Cómo explicar que el tamaño de la muestra no influye en la duración del proyecto

Dígales que es como construir una nueva autopista de cuatro carriles hacia una parte remota del país. Ya sea que esa carretera sea utilizada por 100 automóviles por día o por 1000 automóviles por día, el esfuerzo para crear la carretera será aproximadamente el mismo.

Por supuesto, si va a soportar 1,000,000 de automóviles al día, tendrá que hacer el camino un poco más robusto, pero de todas formas, tendrá que cortar los mismos árboles, atravesar las mismas montañas, nivelar la misma cantidad de suciedad, y estas actividades son prácticamente un costo fijo sin importar cuántos autos utilicen la carretera.

Dales una calculadora y pídeles que agreguen 1238783423 a 9858238483, el tiempo que demora. luego pídales que agreguen 3423 a 8483 y dígales que espera la respuesta aproximadamente 100000 veces más rápido.

También puede explicar la cantidad de datos (probablemente) los efectos del tiempo que tardará el software en ejecutar no en el tiempo de desarrollo.

Ponlo en el administrador de hablar.

Si construyes una máquina para hacer widgets a 1 widgets por segundo, No importa si lo usas para hacer 100 widgets. o 10000 widgets, la máquina en sí toma el mismo tiempo para construir.

la diferencia está en el tiempo de ejecución, no en el tiempo de compilación.

Todas las clases de administración funcionan en un problema como este con hipotéticas fábricas de widgets.

No uses una analogía. Sólo explícalo.

• Para una cantidad muy pequeña de elementos (10?) es más barato convertirlos manualmente. No escriba un programa en absoluto.
• Para un pequeño número de elementos (100?) valdrá la pena escribir un programa. Es posible que pueda ahorrar al ignorar algunas permutaciones de los datos que son teóricamente posibles, pero que no aparecen en la práctica en el pequeño conjunto de datos. O aparecer en números tan pequeños que el programa pueda rechazarlos y se pueden convertir manualmente. Es factible realizar análisis rápidos en los datos para verificar si los casos de esquina aparecen realmente en los datos. Si no aparecen, pueden ser ignorados.
• Una vez que pase este punto, el tamaño real de los datos no tendrá impacto. Necesita escribir un programa serio que pueda manejar cualquier entrada posible. El programa puede manejar 1,000 artículos o 100,000. Solo demora más en ejecutarse.

La educación es mejor que hablar mal :)

No es realmente una analogía, pero sigo creyendo que es una buena manera de lidiar con este argumento: demostrar que hay un error fatal en él.

Su proyecto anterior incluía (de lo que obtengo) copiar datos con algunas modificaciones.

Si lo hice bien, eso es algo que un equipo de, digamos, 100 contadores puede hacer en unos pocos meses. Entonces, ¿por qué lanzaron a los desarrolladores de software el problema?

Porque al software que creó no le importa si procesará 10 o 10 millones de datos (no exactamente, pero dudo que a sus gerentes les importe la complejidad O(n) ). Por lo tanto, probablemente fue más barato, más rápido y más limpio (proceso menos propenso a errores).

Si eres más radical, incluso puedes sugerir que si no les gusta la rapidez con la que trabaja el equipo de software, siempre pueden llamar a los contadores para que hagan el trabajo a mano.

Esto hizo que la vida de sus gerentes fuera mucho más fácil mientras estaba desarrollando el último proyecto, y ahora, cuando tienen que aplicar la misma lógica para descubrir la siguiente pieza de software, tampoco le importa si va a funcionar en 10 Millones o 4 000 filas, de repente se olvidan de ello.

Creo que en tu caso, los gerentes simplemente están jugando un juego de estimación y están intentando obligue al equipo a trabajar más rápido, señalando la diferencia entre 4000 y 250000 y esperando algo de "culpa". Podría estar equivocado, pero he visto esto hecho antes.

Es una forma terrible de administrar un equipo de programadores (en realidad, cualquier tipo de equipo creativo) y no ayuda a nadie.

Sé que pediste una analogía, pero creo que esa es la técnica incorrecta.

Creo que, como otros han mencionado de pasada, es necesario enfatizar que el tamaño de los datos afecta a tiempo de ejecución , no a tiempo de compilación .
Por lo tanto, divídalos: en realidad tiene dos subproyectos, construyendo y ejecutando. El proyecto de construcción debe (en su mayor parte) ser irrelevante de la cantidad de datos en los que se ejecutará, solo importa los tipos de datos.
En cuanto al tiempo de ejecución, seguro, pueden factorizarlo según el tamaño de los datos (excluyendo cualquier sobrecarga fija no trivial).

Es como si tuvieras que conducir hasta Melbourne, pero primero debes construir el auto.
Claro, conducir a Sydney puede ser más rápido, pero construir el vehículo lleva la misma cantidad de tiempo.
_{De acuerdo, te di una analogía después de todo.}

¿Tal vez un teléfono? Su cliente quiere un teléfono a medida. Si hace 0 llamadas por día o 100 llamadas por día, le tomará la misma cantidad de tiempo crear su teléfono.

Los datos que un teléfono transmite son análogos a los datos copiados por su programa.

Sus administradores parecen confundir el tiempo de desarrollo con el tiempo de ejecución real del programa. Pero su malentendido puede ser diferente. Pueden asumir que hay menos "campos" involucrados. No sólo menos registros de datos. Si hay 100000 campos de datos individuales, sería un esfuerzo de desarrollo masivo en comparación con solo 10 campos. Más trabajo de mapeo de un sistema a otro. En este caso, en realidad pueden ser correctos, pero todavía hay una sobrecarga constante y no puede simplemente dividir por la cantidad de campos para obtener el tiempo.     

Como me gusta describirlo, los datos tienen 2 dimensiones de longitud y anchura. Longitud es el número de registros, ancho es el número total de columnas en todas las tablas

Ahora, cuando desea importar datos, es como obtener un bloque a través de un agujero. Necesita hacer un agujero lo suficientemente grande para la dimensión más pequeña y luego pasar el bloque a través

ahora con 10 millones y 10 mil la dimensión más pequeña sigue siendo el ancho. Por lo tanto, es el ancho el que decide cuánto tiempo se tarda en hacer el agujero.

PARA completar la metáfora, si es la longitud que es más pequeña, simplemente escribiría los datos manualmente

Importo cientos de archivos de clientes cada semana.

Una cosa que he encontrado es que los archivos pequeños generalmente tardan más en desarrollar la importación de datos porque:

• Es menos probable que sigan las reglas (tenemos un archivo estándar estructuras, nunca he visto a un pequeño cliente darnos los datos en el Formato estándar que pedimos, pero los grandes entienden por qué eso es importante)
• Tienden a tener más problemas de integridad de datos, especialmente si son proveniente de un archivo de Excel en lugar de una base de datos (donde archivos provienen de) que ya tenían reglas de integridad de datos construidas in
• Es menos probable que se proporcionen en el mismo formato cada vez.

Hemos descubierto que ahorramos mucho tiempo en el desarrollo al crear un paquete SSIS secundario padre que tiene un proceso hijo estándar y cualquier manipulación necesaria para obtener los datos en la forma del estándar se puede hacer en el padre. De esa manera, se vuelve menos una cuestión de cuántos registros cuando hacemos una estimación, pero una cuestión de cuán cerca de la norma es el archivo que estamos obteniendo. Ahora no recibimos tantas quejas cuando las cosas más pequeñas tardan más en desarrollarse porque no se ajustan al estándar.

Escribir un programa es como contratar a un nuevo empleado. Tienes que enseñarles dónde encontrar los datos, qué hacer con ellos y cómo darte los resultados. Tienes que vigilarlos por un momento para asegurarte de que lo están haciendo bien. Podría tomar un poco más de tiempo entrenarlos si tienen un trabajo complicado / importante o si van a hacer una gran cantidad de trabajo, pero toma una cantidad sustancial de tiempo sin importar qué.

Muchos gerentes están familiarizados con los gastos generales involucrados en la capacitación de un nuevo empleado, por lo que esto podría tener sentido para ellos.

(la analogía se rompe en la medida en que su nuevo empleado es un robot superpoderado que puede hacer el trabajo en una cantidad trivial de tiempo, sin importar cuántos registros le lance, pero espero que haya logrado su objetivo para entonces. )