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

Temos grandes projetos corporativos, que normalmente envolvem a cópia de dados de um banco de dados de origem para um banco de dados de destino e a configuração de vários aplicativos adicionais que sincronizam esses dados, etc.

O último projeto continha 250.000 itens (linhas de dados). O próximo projeto conterá apenas 4.000 itens. Os gerentes de projeto / pessoas de negócios acreditam que o projeto deve ter 1/10 do tempo para ser concluído porque é apenas uma fração do tamanho do último projeto.

Qual é uma boa analogia que posso usar para explicar que escrever código para transferir dados de um sistema para outro leva a mesma quantidade, independentemente do número de itens - gravá-lo para 1 item ou para 100.000.000 levará aproximadamente a mesma quantidade de tempo de uma programação ponto de vista.

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

É verdade que, se ele suportar 1.000.000 de carros por dia, você terá que tornar a estrada um pouco mais robusta, mas, independentemente 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 usem a estrada.

Dê a eles uma calculadora e peça para adicionar 1238783423 a 9858238483, tempo quanto tempo leva. peça para adicionar 3423 a 8483 e diga que espera a resposta aproximadamente 100000 vezes mais rápido.

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

Coloque-o na fala do gerente.

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

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

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

Não use uma analogia. Apenas explique.

• Para um número muito pequeno de itens (10?), É mais barato converter manualmente. Não escreva um programa.
• Para um pequeno número de itens (100?), Vale a pena escrever um programa. Você pode economizar ao ignorar algumas permutações de dados que são teoricamente possíveis, mas não aparecem na prática no pequeno conjunto de dados. Ou apareça em números tão pequenos que o programa possa rejeitá-los e eles 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, podem ser ignorados.
• Depois de passar esse ponto, o tamanho real dos dados não tem impacto. Você precisa escrever um programa sério que possa lidar com qualquer entrada possível. O programa pode lidar com 1.000 itens ou 100.000. Leva apenas mais tempo para ser executado.

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

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

Seu projeto anterior incluía (pelo que recebi) a cópia de dados com algumas modificações.

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

Como o software que você criou não se importa se processará 10 ou 10 milhões de dados (não exatamente, mas duvido que seus gerentes se preocupem com a O(n)complexidade). Portanto, provavelmente era mais barato, mais rápido e mais limpo (processo menos propenso a erros).

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

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

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

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

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

Acredito, como outros já mencionaram, que você precisa enfatizar que o tamanho dos dados afeta o tempo de execução , não o tempo de construção .
Então, divida para eles - você realmente tem dois subprojetos, construindo e executando. O projeto de construção deve (na maior parte) ser irrelevante para a quantidade de dados em que ele será executado, apenas importa os tipos de dados.
Quanto ao tempo de execução - com certeza, eles podem levar isso em consideração de acordo com o tamanho dos dados (excluindo qualquer sobrecarga fixa não trivial).

É como se você tivesse que dirigir para Melbourne - mas primeiro você precisa 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 deseja um telefone personalizado. Se ele fizer 0 ligações por dia ou 100 ligações por dia, levaria a mesma quantidade de tempo para criar seu telefone.

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

Seus gerentes parecem confundir o tempo de desenvolvimento com o tempo de execução real 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 100000 campos de dados individuais, seria um grande esforço de desenvolvimento em comparação com apenas 10 campos. Mais trabalho de mapeamento de sistema para sistema. Nesse caso, eles podem estar realmente corretos, mas ainda há uma sobrecarga constante envolvida e você não pode simplesmente dividir pelo número de campos para obter o tempo.

Como eu 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 obter um bloco através de um buraco. Você precisa fazer um furo grande o suficiente para a menor dimensão e, em seguida, transportar o bloco

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

Para completar a metáfora, se o comprimento for menor, digite apenas 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:

• É menos provável que eles sigam as regras (temos estruturas de arquivos padrão, nunca vi um cliente pequeno nos fornecer os dados no formato padrão que solicitamos, mas os grandes entendem por que isso é importante)
• Eles tendem a ter mais problemas de integridade de dados, especialmente se vierem de um arquivo do Excel e não de um banco de dados (de onde os arquivos grandes tendem a vir), que já tinham regras de integridade de dados incorporadas
• É menos provável que eles sejam fornecidos no mesmo formato todas as vezes.

Descobrimos que economizamos muito tempo em desenvolvimento criando 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 próximo do padrão está o arquivo que estamos recebendo. Agora não recebemos tantas reclamações quando coisas menores levam mais tempo para serem desenvolvidas porque 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 fornecer os resultados. Você precisa ficar de olho neles por um tempo para garantir que eles estejam fazendo o que é certo. Pode demorar um pouco mais para treiná-los se eles tiverem um trabalho complicado / importante ou se eles farão 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 as despesas gerais envolvidas no treinamento de um novo funcionário; portanto, isso pode fazer sentido para eles.

(a analogia é interrompida na medida em que seu novo funcionário é um robô superpoderoso que pode fazer o trabalho em uma quantidade trivial de tempo, independentemente de quantos registros você lance neles, mas espero que você tenha entendido sua opinião até então).