Como explicar que o tamanho da amostra não influencia o tamanho do projeto

Diga-lhes que é como construir uma nova rodovia de quatro pistas para uma parte remota do país. Se essa estrada é usada por 100 carros por dia ou 1000 carros por dia, o esforço para criar a estrada será praticamente o mesmo.

Concedido, se ele vai suportar 1.000.000 de carros por dia, você terá que tornar a estrada um pouco mais robusta, mas independente disso, você terá que cortar as mesmas árvores, atravessar as mesmas montanhas, nivelar a mesma quantidade de sujeira, e essas atividades são praticamente um custo fixo, não importa quantos carros usam a estrada.

Dê a eles uma calculadora e peça que eles adicionem 1238783423 a 9858238483, tempo que leva. em seguida, peça para eles adicionarem 3423 a 8483 e dizerem que você espera a resposta aproximadamente 100.000 mais rápido.

Você também pode explicar que a quantidade de dados (provavelmente) afeta o tempo que o software levará para executar o tempo de desenvolvimento.

Coloque em manager speak.

Se você criar uma máquina para criar widgets com 1 widgets por segundo, não importa se você usá-lo para fazer 100 widgets ou 10000 widgets, a própria máquina leva o mesmo tempo para construir.

a diferença está no tempo de execução, não no tempo de compilação.

Todas as classes de gerenciamento trabalham com problemas como este com fábricas hipotéticas de widgets.

Não use uma analogia. Apenas explique isso.

• Para um número muito pequeno de itens (10?), é mais barato converter manualmente. Não escreva nenhum programa.
• Para um pequeno número de itens (100?), vale a pena escrever um programa. Você pode economizar, ignorando algumas permutações dos dados teoricamente possíveis, mas não aparecem na prática no pequeno conjunto de dados. Ou aparecem em números tão pequenos que o programa pode rejeitá-los e podem ser convertidos manualmente. É possível executar análises rápidas nos dados para verificar se os casos de canto realmente aparecem nos dados. Se eles não aparecerem, eles podem ser ignorados.
• Depois de passar este ponto, o tamanho real dos dados não tem impacto. Você precisa escrever um programa sério que possa manipular qualquer entrada possível. O programa pode manipular 1.000 itens ou 100.000. Leva apenas mais tempo para ser executado.

A educação é melhor do que falar abaixo:)

Não é realmente uma analogia, mas eu ainda acredito em uma boa maneira de lidar com esse argumento: demonstrar que há uma falha fatal nele.

Seu projeto anterior incluiu (pelo que eu entendi) copiar dados com algumas modificações nele.

Se eu entendi direito, isso é algo que uma equipe de, digamos, 100 contadores pode fazer em questão de alguns meses. Então, por que eles lançaram desenvolvedores de software no problema?

Porque o software que você criou não importa se ele processará 10 ou 10 milhões de dados (não exatamente, mas duvido que seus gerentes se importem com O(n) complex). Assim, provavelmente foi mais barato, mais rápido e mais limpo (menos processo propenso a erros).

Se você é mais radical, pode até sugerir que, se eles não gostarem da rapidez com que a equipe de software trabalha, eles podem sempre chamar os contadores para fazer o trabalho manualmente.

Isso facilitou muito a vida de seus gerentes enquanto você estava desenvolvendo o último projeto, e agora, quando eles têm que aplicar a mesma lógica para descobrir o próximo software também não se importa se ele vai funcionar em 10 milhões ou 4 000 linhas, eles de repente se esquecem disso.

Acho que, no seu caso, os gerentes estão simplesmente jogando um jogo de estimativas e estão tentando forçar a equipe a trabalhar mais rápido, apontando a diferença entre 4000 e 250000 e esperando por alguma 'culpa'. Eu posso estar errado, mas eu já vi isso feito antes.

É uma maneira terrível de gerenciar uma equipe de programadores (na verdade, qualquer tipo de equipe criativa) e isso não ajuda ninguém.

Eu sei que você pediu uma analogia, mas acho que essa é a técnica errada.

Eu acredito, como outros já mencionaram, que você precisa enfatizar que o tamanho dos dados afeta tempo de execução , não tempo de compilação . Então, divida isso para eles - você realmente tem dois subprojetos, construindo e executando. O projeto de construção deve (na maioria das vezes) ser irrelevante em relação à quantidade de dados em que será executado, somente importa os tipos de dados.
Quanto ao tempo de execução - claro, eles podem fatorar isso de acordo com o tamanho dos dados (excluindo qualquer sobrecarga fixa não trivial).

É como se você tivesse que dirigir até Melbourne - mas primeiro você tem que construir o carro.
Claro, dirigir para Sydney pode ser mais rápido - mas construir o veículo leva a mesma quantidade de tempo.
_{Ok, eu te dei uma analogia afinal.}

Talvez um telefone? Seu cliente quer um telefone personalizado. Se ele fizer 0 chamadas por dia ou 100 chamadas por dia, levaria o mesmo tempo para criar seu telefone.

Os dados transmitidos por um telefone são análogos aos dados copiados pelo seu programa.

Seus gerentes parecem confundir o tempo de execução com o tempo real de execução do programa. Mas seu mal-entendido pode ser diferente. Eles podem assumir que há menos "campos" envolvidos. Não apenas menos registros de dados. Se houver 100.000 campos de dados individuais, seria um grande esforço de desenvolvimento comparado a apenas 10 campos. Mais trabalho de mapeamento de sistema para sistema. Nesse caso, eles podem estar corretos, mas ainda há alguma sobrecarga constante envolvida e você não pode simplesmente dividir pelo número de campos para obter o tempo.

Como gosto de descrever, os dados têm 2 dimensões de comprimento e largura. Comprimento é o número de registros, largura é o número total de colunas em todas as tabelas

Agora, quando você deseja importar dados, é como receber um bloco em um buraco. Você precisa fazer um buraco grande o suficiente para a menor dimensão, e depois carregar o bloco até

agora com 10 milhões e 10 mil a menor dimensão ainda é a largura. Então é a largura que decide quanto tempo leva para fazer o buraco.

Para completar a metáfora, ff é o comprimento menor que você digitaria os dados manualmente

Eu importo centenas de arquivos de clientes toda semana.

Uma coisa que descobri é que os arquivos pequenos geralmente levam mais tempo para desenvolver a importação de dados porque:

• Eles são menos propensos a seguir as regras (temos arquivo padrão estruturas, eu nunca vi um pequeno cliente nos dar os dados no formato padrão que pedimos, mas grandes entendem por que isso é importante)
• Eles tendem a ter mais problemas de integridade de dados, especialmente se forem vindo de um arquivo do Excel, em vez de um banco de dados (onde o grande os arquivos tendem a vir) que já tinham regras de integridade de dados em
• É menos provável que sejam fornecidos no mesmo formato todas as vezes.

Descobrimos que economizamos muito tempo no desenvolvimento construindo um pacote SSIS filho pai que possui um processo filho padrão e qualquer manipulação necessária para obter os dados na forma do padrão pode ser feita no pai. Dessa forma, torna-se menos uma questão de quantos registros quando fazemos uma estimativa, mas uma questão de quão perto do stanrdard é o arquivo que estamos recebendo. Nós agora não recebemos tantas reclamações quando as coisas menores demoram mais para se desenvolver porque elas não se encaixam no padrão.

Escrever um programa é como contratar um novo funcionário. Você precisa ensiná-los onde encontrar os dados, o que fazer com eles e como obter os resultados. Você tem que ficar de olho neles por um tempo para ter certeza de que eles estão fazendo certo. Pode levar um pouco mais de tempo para treiná-los se eles tiverem um trabalho complicado / importante ou se fizerem uma quantidade muito grande de trabalho, mas isso leva uma quantidade substancial de tempo, não importa o quê.

Muitos gerentes estão familiarizados com a sobrecarga envolvida no treinamento de um novo funcionário, portanto isso pode fazer sentido para eles.

(a analogia se desfaz na medida em que seu novo funcionário é um robô superpoderoso que pode fazer o trabalho em um período de tempo trivial, não importa quantos registros você jogue neles, mas espero que você tenha feito seu ponto até lá. )