Comment expliquer que la taille de l'échantillon n'influence pas la longueur du projet

Nous avons des projets de grandes entreprises qui impliquent normalement la copie de données d'une base de données source vers une base de données de destination, puis la configuration d'un certain nombre d'applications supplémentaires qui synchronisent ces données, etc.

Le dernier projet contenait 250 000 éléments (lignes de données). Le prochain projet ne contiendra que 4 000 articles. Les responsables de projet / les hommes d’affaires estiment que le projet devrait durer 1/10 du temps, car il ne représente qu’une fraction de la taille du dernier projet.

Quelle bonne analogie puis- je utiliser pour expliquer que l'écriture de code pour transférer des données d'un système à un autre prend le même montant quel que soit le nombre d'éléments - l'écrire pour 1 élément ou pour 100 000 000 nécessitera à peu près le même temps d'une programmation point de vue.

Dites-leur que c'est comme construire une nouvelle autoroute à quatre voies dans une région reculée du pays. Que cette route soit utilisée par 100 voitures par jour ou par 1 000 voitures par jour, l'effort de création de la route sera à peu près le même.

Certes, si elle doit supporter 1 000 000 voitures par jour, vous devrez rendre la route un peu plus robuste, mais peu importe, vous devrez abattre les mêmes arbres, foncer dans les mêmes montagnes, niveler le même montant de la saleté, et ces activités sont à peu près un coût fixe, peu importe combien de voitures utilisent la route.

Donnez-leur une calculatrice et demandez-leur d'ajouter 1238783423 à 9858238483, le temps qu'il faut. Puis, demandez-leur d’ajouter 3423 à 8483 et dites-leur que vous attendez la réponse environ 100 000 fois plus rapidement.

Vous pouvez également expliquer que la quantité de données influe (probablement) sur la durée nécessaire au logiciel pour s'exécuter, et non sur le temps de développement.

Mettez-le en gestionnaire parler.

Si vous construisez une machine pour fabriquer des widgets à 1 widget par seconde, peu importe que vous l'utilisiez pour créer 100 widgets ou 10 000 widgets, la machine prend elle-même le même temps de construction.

la différence est au moment de l'exécution, pas au moment de la construction.

Toutes les classes de gestion travaillent sur un problème comme celui-ci avec des fabriques de widgets hypothétiques.

Ne pas utiliser une analogie. Explique-le simplement.

• Pour un très petit nombre d’articles (10?), Il est moins coûteux de convertir manuellement. Ne pas écrire un programme du tout.
• Pour un petit nombre d’articles (100?), Il vaudra la peine d’écrire un programme. Vous pourrez peut-être réaliser des économies en ignorant certaines permutations des données théoriquement possibles, mais n'apparaissent pas dans la pratique dans le petit jeu de données. Ou apparaissez en si petit nombre que le programme peut les rejeter et ils peuvent être convertis manuellement. Il est possible d'exécuter des analyses rapides sur les données pour vérifier si les cas de coin apparaissent réellement dans les données. S'ils n'apparaissent pas, ils peuvent être ignorés.
• Une fois ce point passé, la taille réelle des données n’a plus d’impact. Vous devez écrire un programme sérieux capable de gérer toutes les entrées possibles. Le programme peut gérer 1 000 articles ou 100 000. Cela prend juste plus de temps à courir.

L'éducation est meilleure que de parler :)

Ce n’est pas vraiment une analogie, mais je crois toujours que c’est un bon moyen de traiter cet argument: démontrer qu’il comporte un défaut fatal.

Votre projet précédent incluait (d'après ce que j'ai obtenu) la copie des données avec quelques modifications.

Si j’ai bien compris, c’est quelque chose qu’une équipe de 100 comptables peut faire en quelques mois. Alors pourquoi ont-ils jeté les développeurs de logiciels sur le problème?

Parce que le logiciel que vous avez créé ne veut pas savoir s'il traitera 10 ou 10 millions de données (pas exactement, mais je doute que vos gestionnaires se soucient de la O(n)complexité). Ainsi, il était probablement moins cher, plus rapide et plus propre (processus moins sujet aux erreurs).

Si vous êtes plus radical, vous pourriez même suggérer que s’ils n’apprécient pas la vitesse de travail de l’équipe des logiciels, ils peuvent toujours faire appel à des comptables pour effectuer le travail à la main.

Cela a beaucoup simplifié la vie de vos responsables lors de l’élaboration du dernier projet. Désormais, ils doivent appliquer la même logique pour déterminer si le prochain logiciel ne se soucie pas de savoir s’il fonctionnera sur 10 millions ou plus. 000 lignes, ils l'oublient soudainement.

Je pense que dans votre cas, les managers jouent simplement à un jeu d'estimation et tentent de forcer l'équipe à travailler plus vite, en soulignant la différence entre 4000 et 250000 et en espérant une «culpabilité». Je peux me tromper, mais j'ai déjà vu cela auparavant.

C'est un moyen terrible de gérer une équipe de programmeurs (en fait n'importe quel type d'équipe créative) et cela n'aide personne.

Je sais que vous avez demandé une analogie, mais je pense que ce n'est pas la bonne technique.

Comme d’autres l'ont déjà mentionné, je pense que vous devez souligner que la taille des données affecte le temps d'exécution , pas le temps de construction .
Donc, décomposez-les pour vous - vous avez en fait deux sous-projets, la construction et en cours d'exécution. Le projet de construction doit (dans la plupart des cas) être indifférent au volume de données sur lequel il sera exploité, il importe uniquement de connaître le type de données.
En ce qui concerne l'exécution, ils peuvent certainement en tenir compte en fonction de la taille des données (à l'exclusion de tout surdébit fixe non trivial).

C'est comme si vous deviez conduire à Melbourne - mais vous devez d'abord construire la voiture.
Bien sûr, aller à Sydney pourrait être plus rapide, mais la construction du véhicule prend le même temps.
_{D'accord, je vous ai donné une analogie après tout.}

Peut-être un téléphone? Votre client veut un téléphone sur mesure. S'il passe 0 appels par jour ou 100 appels par jour, la création de son téléphone prendrait le même temps.

Les données transmises par un téléphone sont analogues aux données copiées par votre programme.

Vos gestionnaires semblent confondre dev-time avec le temps d'exécution réel du programme. Mais leur malentendu peut être différent. Ils peuvent supposer qu'il y a moins de "champs" impliqués. Pas seulement moins d'enregistrements de données. S'il y a 100 000 champs de données individuels, l'effort de développement sera énorme comparé à seulement 10 champs. Plus de travail de mappage de système à système. Dans ce cas, ils sont peut-être corrects, mais il y a toujours une surcharge constante et vous ne pouvez pas simplement diviser par le nombre de champs pour obtenir l'heure.

Comme je me plais à décrire, les données ont 2 dimensions longueur et largeur. Longueur est le nombre d'enregistrements, largeur est le nombre total de colonnes dans toutes les tables

Maintenant, quand vous voulez importer des données, c'est comme si vous bloquiez un trou. Vous devez faire un trou assez grand pour la plus petite dimension, puis porter le bloc à travers

maintenant, avec 10 millions et 10 000, la plus petite dimension est toujours la largeur. C'est donc la largeur qui détermine le temps qu'il faut pour percer le trou.

POUR compléter la métaphore, si c’est la longueur qui est plus petite, il vous suffit de taper les données manuellement

J'importe des centaines de fichiers clients chaque semaine.

Une chose que j'ai constatée est que les petits fichiers mettent généralement plus de temps à développer l'importation de données car:

• Ils sont moins susceptibles de suivre les règles (nous avons des structures de fichiers standard, je n’ai jamais vu un petit client nous donner les données dans le format standard que nous demandons mais les grands comprennent en quoi cela est important)
• Ils ont tendance à avoir plus de problèmes d'intégrité des données, en particulier s'ils proviennent d'un fichier Excel plutôt que d'une base de données (d'où proviennent généralement les fichiers volumineux) qui comportait déjà des règles d'intégrité des données intégrées.
• Ils sont moins susceptibles d'être fournis dans le même format à chaque fois.

Nous avons constaté que nous gagnions beaucoup de temps en développement en créant un package SSIS enfant parent doté d'un processus enfant standard et que toute manipulation nécessaire pour obtenir les données sous la forme de la norme puisse être effectuée dans le parent. De cette manière, le nombre d'enregistrements lors de l'estimation est moins un problème que de savoir à quel point le fichier que nous obtenons est proche de la norme. Nous ne recevons plus autant de plaintes lorsque les petites choses mettent plus de temps à se développer car elles ne correspondent pas à la norme.

Écrire un programme, c'est un peu comme engager un nouvel employé. Vous devez leur apprendre où trouver les données, quoi en faire et comment vous donner les résultats. Vous devez les surveiller un petit moment pour vous assurer qu'ils le font bien. Cela pourrait prendre un peu plus de temps pour les former s'ils ont un travail compliqué / important ou s'ils vont faire un travail très important, mais cela prend beaucoup de temps, quoi qu'il en soit.

De nombreux gestionnaires connaissent les frais généraux liés à la formation d'un nouvel employé. Cela peut donc leur sembler logique.

(L'analogie disparaît dans la mesure où votre nouvel employé est un robot surpuissant qui peut faire le travail en un temps banal, peu importe le nombre d'enregistrements que vous lui lancez, mais j'espère que vous avez bien expliqué votre point de vue.)