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

Tenemos grandes proyectos empresariales que normalmente implican copiar datos de una base de datos de origen a una base de datos de destino y luego configurar una serie de aplicaciones adicionales que sincronizan estos datos, etc.

El último proyecto contenía 250,000 artículos (filas de datos). El próximo proyecto solo contendrá 4,000 artículos. Los gerentes de proyecto / gente de negocios creen que el proyecto debería ser 1/10 del tiempo de finalización porque es solo una fracción del tamaño del último proyecto.

¿Cuál es una buena analogía que puedo usar para explicar que escribir código para transferir datos de un sistema a otro requiere la misma cantidad independientemente de los números? Escribirlo para 1 elemento o para 100,000,000 tomará aproximadamente la misma cantidad de tiempo de una programación punto de vista.

Dígales que es como construir una nueva autopista de cuatro carriles a una parte remota del país. Ya sea que ese camino sea utilizado por 100 autos al día o 1000 autos al día, el esfuerzo para crear el camino será casi el mismo.

De acuerdo, si va a soportar 1,000,000 de autos al día, tendrá que hacer que el camino sea un poco más robusto, pero de todos modos, tendrá que cortar los mismos árboles, volar a través de las mismas montañas, nivelar la misma cantidad de tierra, y estas actividades son más o menos un costo fijo, sin importar cuántos automóviles utilicen la carretera.

Dales una calculadora y pídeles que agreguen 1238783423 a 9858238483, el tiempo que tarda. 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) afecta el tiempo que tardará el software en ejecutarse, no el tiempo de desarrollo.

Ponlo en el gerente de hablar.

Si construye una máquina para hacer widgets a 1 widgets por segundo, no importa si la usa para hacer 100 widgets o 10000 widgets, la máquina misma tarda el mismo tiempo en construirse.

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

Todas las clases de gestión funcionan en problemas como este con fábricas de widgets hipotéticos.

No uses una analogía. Solo explícalo.

• Para un número muy pequeño de elementos (¿10?), Es más barato convertirlos manualmente. No escribas un programa en absoluto.
• Para un pequeño número de artículos (¿100?) Valdrá la pena escribir un programa. Es posible que pueda ahorrar si ignora 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 aparece en números tan pequeños que el programa puede rechazarlos y convertirlos manualmente. Es factible realizar análisis rápidos en los datos para verificar si los casos de esquina realmente aparecen en los datos. Si no aparecen, pueden ser ignorados.
• Una vez que pasa este punto, el tamaño real de los datos no tiene impacto. Necesita escribir un programa serio que pueda manejar cualquier entrada posible. El programa puede manejar 1,000 artículos o 100,000. Solo lleva más tiempo correr.

La educación es mejor que hablar :)

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

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

Si acerté, eso es algo que un equipo de, por ejemplo, 100 contadores puede hacer en cuestión de unos pocos meses. Entonces, ¿por qué arrojaron a los desarrolladores de software al problema?

Debido a que el software que creó no le importa si procesará 10 o 10 millones de datos (no exactamente, pero dudo que sus gerentes se preocupen por la O(n)complejidad). 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 podrías sugerir que si no les gusta lo rápido que trabaja el equipo de software, siempre pueden llamar a los contadores para que hagan el trabajo a mano.

Esto hizo la vida de sus gerentes mucho más fácil mientras desarrollaba el último proyecto, y ahora, cuando tienen que aplicar la misma lógica para descubrir que el siguiente software no le importa si funcionará en 10 millones o 4 000 filas, de repente se olvidan de eso.

Creo que en su caso los gerentes simplemente están jugando un juego de estimación y están tratando de obligar 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, como otros han mencionado de pasada, que debe enfatizar que el tamaño de los datos afecta el tiempo de ejecución , no el tiempo de construcción .
Por lo tanto, desglose por ellos: en realidad tiene dos subproyectos, construir y ejecutar. El proyecto de construcción debería (en su mayor parte) ser irrelevante de la cantidad de datos que se ejecutarán, solo importa los tipos de datos.
En cuanto al tiempo de ejecución, seguro, pueden factorizarlo de acuerdo con el tamaño de los datos (excluyendo cualquier sobrecarga fija no trivial).

Es como si tuviera que conducir a Melbourne, pero primero tiene que construir el automóvil.
Claro, conducir a Sydney podría ser más rápido, pero construir el vehículo lleva la misma cantidad de tiempo.
_{Está bien, te di una analogía después de todo.}

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

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

Sus gerentes parecen confundir el tiempo de desarrollo con el tiempo de ejecución real del programa. Pero su malentendido puede ser diferente. Pueden suponer que hay menos "campos" involucrados. No solo 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 sistema a sistema. En este caso, en realidad pueden ser correctos, pero todavía hay una sobrecarga constante involucrada y no puede simplemente dividir por el número de campos para obtener el tiempo.

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

Ahora, cuando desea importar datos, es como hacer que un bloque atraviese un agujero. Debe hacer un agujero lo suficientemente grande para la dimensión más pequeña y luego llevar 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 lleva hacer el agujero.

Para completar la metáfora, si es la longitud más pequeña, simplemente escriba 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 estructuras de archivos estándar, nunca he visto a un cliente pequeño que nos brinde los datos en el formato estándar que solicitamos, pero los grandes entienden por qué eso es importante)
• Tienden a tener más problemas de integridad de datos, especialmente si provienen de un archivo de Excel en lugar de una base de datos (de donde provienen los archivos grandes) que ya tenían reglas de integridad de datos incorporadas
• 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 padre-hijo 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 esta forma, se convierte en menos un problema de cuántos registros cuando hacemos una estimación, pero un problema de qué tan cerca del estándar está 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. Debe enseñarles dónde encontrar los datos, qué hacer con ellos y cómo obtener los resultados. Debes vigilarlos un poco para asegurarte de que lo están haciendo bien. Puede 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 lleva una cantidad considerable 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 superpoder que puede hacer el trabajo en un período de tiempo trivial, sin importar cuántos registros les arroje, pero espero que haya hecho su punto para entonces).