Meu chefe tem um caso grave de "Não inventado aqui" [fechado]

66

Meu departamento é especializado na conversão de dados de clientes em nosso esquema de banco de dados para que eles possam usar nosso software.

No momento, temos aplicativos C # que demoram um IDataReader(99% do tempo SqlDataReader), executam alguma limpeza e mapeamento, inserem-no em um DataRowobjeto e, em seguida, usam a SqlBulkCopypara inseri-lo em nosso banco de dados.

Às vezes (especialmente quando o banco de dados de origem contém imagens como varbinaryobjetos), esse processo pode realmente atrapalhar com uma transferência SQL do servidor para o aplicativo, para então virar e voltar ao servidor.

Sinto que, se reescrevemos algumas das conversões como pacotes SSIS, isso poderia acelerar bastante as coisas. No entanto, o maior obstáculo em que eu continuo encontrando é quando meu chefe, na moda Não inventou aqui , recua e diz: "E se a Microsoft abandonar o suporte ao SSIS? Teremos todo esse código obsoleto e seremos ferrados".

Esta não é a primeira vez que clico em "E se eles removerem esse recurso ...?" resposta do meu chefe. Não tenho tempo para escrever a conversão da maneira antiga, autodidata do SSIS e também escrever a nova maneira de demonstrar / testar os benefícios (Nenhum de nós usou o SSIS, portanto haveria um período em que tem que aprender a usá-lo).

O que devo fazer nesta situação? Pare de empurrar a nova tecnologia? Espere até ele sair do departamento (eu sou a segunda pessoa mais Sr. no departamento depois dele, mas pode levar anos até que ele desista / se aposente)? Encontrou uma nova maneira de fazê-lo parar de ter medo de ferramentas de terceiros?

Scott Chamberlain
fonte
3
Você pode achar útil a discussão sobre c2 em NotInventedHere .
15
Minha primeira pergunta do ponto de vista comercial é: Is it broken?- Esta é uma pergunta booleana. "Pode ser melhorado." é equivalente a "Não".
Joel Etherton
39
Não tenho certeza se este é NIH. Parece-me seu chefe tem uma preocupação válida, considerando como Microsoft está com bastante o historial de fim do suporte para a tecnologia que os desenvolvedores estavam construindo software sério com ...
Mason Wheeler
11
@JoelEtherton Não inteiramente. O desempenho não é booleano e pode afetar os usuários finais, dependendo de onde está a desaceleração. Esta é (em parte) uma questão de desempenho.
Izkata 18/01/2013
9
@MasonWheeler, se você está pensando assim, tudo deve ser escrito em C ou assembly. Quero dizer, e se a Microsoft abandonar o suporte ao ASP.Net !?
Earlz

Respostas:

110

Vou dar uma olhada nisso do ponto de vista gerencial, mas lembre-se de que não tenho todos os detalhes. Vou resumir o que vejo:

  1. Desenvolvedor de nível médio, o chamaremos de "Scott", recomenda a reescrita do código legado no SSIS para melhorar o desempenho do processo importante ProcessA.
  2. No momento, o ProcessA está se comportando em um estado de funcionamento sem problemas importantes conhecidos.
  3. ProcessA é escrito com ferramentas proprietárias, usando o conhecimento comum ou potencialmente tribal para manter.
  4. A recomendação para reescrever exigirá novas ferramentas de suporte.
  5. A equipe atual não possui experiência / conhecimento documentado com as novas ferramentas.
  6. Novas ferramentas são substituições relativamente recentes para ferramentas mais antigas, e o suporte a essas ferramentas pode mudar razoavelmente em quatro trimestres de negócios.

Nesta perspectiva, tudo o que vejo é um grande desembolso de dinheiro por parte da empresa para melhorar um processo que não está quebrado . Do ponto de vista técnico, posso ver o apelo, mas quando você se dedica a isso, simplesmente não faz sentido nos negócios fazer essa alteração. Se você tivesse uma equipe com experiência documentada com o SSIS e benchmarks para mostrar melhorias maciças nesse processo (lembre-se de que as melhorias maciças DEVEM ser equivalentes a $$$), o resultado pode ser um pouco diferente. Como está agora, porém, eu teria que concordar com o gerenciamento (em algum lugar em que uma árvore acabou de morrer).

Se você deseja promover a adoção do SSIS e potencialmente levar a esse refator, precisará adquirir essa experiência e treinamento com projetos menores e menos importantes. Forneça referências e suporte para o SSIS e verifique se toda a infraestrutura e suporte estão em vigor antes que o gerenciamento considere fazer a alteração. Depois que você tiver a ferramenta em uso em outro lugar, as pessoas da equipe tiverem experiência com esse uso e um fator de "conforto" dos negócios que o suporte não mudará e arrancará tudo, você terá mais chances de influenciar alguém do seu ponto de vista. Sem eles, você está latindo na árvore errada com esse argumento.

Por mais estúpido que pareça, às vezes o "melhor" caminho não é o melhor.

Editar: em resposta a algumas atualizações da pergunta, publicarei uma pequena modificação na minha resposta.

Se o processo estiver passando por algum tipo de sofrimento, reescrevê-lo ainda será um empreendimento caro. Você pode considerar o custo do ajuste fino do código existente contra a reescrita do pacote. Considere os impactos não apenas no software, mas também em qualquer processo de interface humana. Ao tentar obter a adesão da gerência a uma reescrita, ainda assim o custo será sempre baixo. A menos que você possa mostrar que a aflição atual está custando dinheiro agora ou se tornará grande no conjunto, a gerência ainda não verá o benefício. Esse custo pode não ser necessariamente de natureza financeira. Se a desaceleração comprometer um sistema que causa tempo de inatividade, introduzir vetores de intrusão ou algum outro sintoma "difícil de quantificar", talvez seja necessário encontrar uma maneira de converter esse problema em um risco monetário equivalente. Um vetor de intrusão, por exemplo, pode levar a uma invasão que pode resultar em dados perdidos, roubados ou corrompidos. A empresa pode perder a reputação ou pode falhar em uma auditoria de segurança necessária. A chave é fazer com que o gerente em questão reconheça os benefícios quantificáveis ​​da mudança.

Joel Etherton
fonte
Um problema que vejo com esse argumento é que a felicidade dos desenvolvedores está em jogo. Isso nunca é considerado nessas decisões de negócios. Parece que sempre acaba custando aos negócios, perdendo desenvolvedores experientes.
Joe Phillips
@ JoePhillips: eu não diria que não é fatorado, mas acho que é mais uma consideração agregada. No nível mais simples, a empresa deve vencer, mas se padrões e práticas ruins continuarem com o tempo, os serviços ou produtos sofrem diretamente com as práticas ou com o tédio dos desenvolvedores. Eu arquivaria isso sob o aviso de isenção de responsabilidade "Não tenho todos os detalhes" em minha postagem. Essa pergunta pode ser uma indicação de um problema maior, mas isso seria muito difícil de determinar com os detalhes fornecidos na pergunta.
Joel Etherton
Parabéns, boa resposta e edição sólida. @JoePhillips, infelizmente, os desenvolvedores geralmente recebem o peso das decisões fiscais de gerenciamento. Pensei em um recurso muito bom para um projeto; Eu até tive feedback dos clientes que eles queriam, mas não garantiu receita suficiente, então a ideia foi cortada. E é assim que o biscoito se desintegra ou queima. Então eu posso ver os dois lados aqui.
Greg
5
Como essa resposta é aceita, isso é meio que discutível, mas eu sinto que isso perde o espírito da pergunta - completamente. O terceiro parágrafo da pergunta implica que o processo atual está quebrado. Obviamente, se você vir apenas a definição restrita de "contanto que funcione", ela não está quebrada. Mas essa é uma definição inútil. Um processo também é interrompido quando há uma maneira óbvia de melhorá-lo drasticamente. Do ponto de vista comercial, isso significa que poderia ser muito mais barato, mais confiável etc.
Konrad Rudolph
@ KonradRudolph: Não sei quando esse parágrafo foi adicionado, mas não estava lá quando postei minha resposta. Não havia nada na pergunta original que sugerisse que o processo estava apresentando algum problema. Lendo os primeiros comentários, você pode ver que isso foi quase um consenso entre as pessoas que estavam respondendo à pergunta.
Joel Etherton
37

Quebrar as coisas é uma habilidade

Já trabalhei em muitos lugares que adotaram o argumento "se não está quebrado" a ponto de não conseguirem inovar e, quando finalmente são forçados a inovar, reagem mudando tudo . Simplesmente porque eles não têm a experiência de quebrar coisas .

É preciso maturidade, habilidade e experiência para quebrar as coisas.

As equipes de desenvolvimento que sempre jogam com segurança são as mais fáceis de serem superadas por um concorrente. Somente equipes que falharam, cometeram erros e quebraram coisas são capazes de realmente fazer avaliações honestas de riscos.

Mantendo o Status Quo

Embora seja verdade, o sistema atual atende aos requisitos comerciais atuais. Isso não é verdade para as futuras mudanças imprevistas nesses requisitos. Como diz o velho provérbio, "a sorte prefere o preparado".

Esta pergunta não tem nada a ver com SQL ou desempenho. É sobre fazer a pergunta "existe uma maneira melhor?" e não ter medo de tentar uma alternativa.

Seu chefe sofre de um caso de Como manter o status quo .

Os Maias

Nada está realmente funcionando perfeitamente.

Os maias continuavam cultivando sua comida nas encostas das montanhas. Até que todos os nutrientes foram lavados e eles não tinham como alimentar seu povo. Eles continuaram fazendo as coisas da mesma maneira até que fosse tarde demais.

Supondo que você tenha tempo para corrigir um problema quando o problema se apresentar é um erro.

insira a descrição da imagem aqui

O que fazer?

Seu chefe sofre de um caso de condicionamento. As pessoas que aceitam o status quo frequentemente o fazem, porque não têm a capacidade de tomar decisões difíceis. Quando confrontados com um desafio, eles tendem a escolher a opção mais próxima do que estão familiarizados.

O medo por ele é uma grande motivação. O medo das condições desconhecidas ou mutáveis ​​abala sua perspectiva do que é o status quo. Ele tenderá a tentar retornar as condições ao normal o mais rápido possível.

Você precisa apresentar idéias de uma maneira não conflitante. Tente encontrar um ponto em comum entre o que você gostaria de fazer e o que já é o status quo. Apresente argumentos que reduzam o medo de mudar e ofereça garantias de que você deseja concluir uma tarefa que não causará mudanças significativas.

Dê passos de bebê

Seria melhor oferecer alterações que movessem o projeto na direção desejada, mas através de pequenos projetos incrementais. Em vez disso, acerte seu chefe com a grande pergunta sobre o suporte ao SSIS. Ofereça-se para criar uma camada de separação no código que permita o plug-in de métodos "alternativos" para processar tabelas com anexos grandes. Em seguida, você pode avançar para recomendar o SSIS com todos os pré-requisitos já adicionados ao projeto. Isso reduz o risco que seu chefe imagina ao aceitar a alteração.

Leva tempo

Minha experiência foi que os que tomam riscos mantêm um projeto em andamento e os que mantêm status quo são como uma parede de tijolos. A persistência é sua única opção para derrubar suas barreiras. Espere continuar ouvindo Não às suas perguntas.

Quando chegar a hora de inovar. Seu chefe se voltará para você rapidamente, porque você demonstra destemor diante da mudança. Algo que uma pessoa com status quo estará procurando e você será recompensado por seus esforços. Mesmo que nenhuma das suas consultas anteriores tenha sido aceita. Você se tornará rapidamente um ativo insubstituível em uma empresa que enfrenta mudanças que adotam mudanças sem mudanças.

Reactgular
fonte
22

Sinto que, se reescrevemos algumas das conversões como pacotes SSIS, isso poderia acelerar bastante as coisas. No entanto, o maior obstáculo em que eu continuo encontrando é quando meu chefe, na moda Não inventou aqui, recua e diz: "E se a Microsoft abandonar o suporte ao SSIS? Teremos todo esse código obsoleto e seremos ferrados".

Na minha opinião, o ceticismo sobre o SSIS é válido.

  • Desenvolvedores experientes odeiam caixas-pretas, e há muita mágica que acontece dentro de um pacote SSIS.
  • O suporte ao controle de origem para pacotes SSIS está extremamente ausente. Difundir e mesclar arquivos dtsx do SSIS pode ser um pesadelo se os pacotes dtsx não forem suficientemente modulares.
    • Por outro lado, os aplicativos de console C # são muito transparentes. Você sempre pode seguir o código para descobrir o que está errado.

Além disso, considere que seu chefe está no gancho se algo der errado.

  • Portanto, ele tem o direito de ter a única / única opinião sobre o assunto.

Não tenho tempo para escrever a conversão da maneira antiga, autodidata do SSIS e também escrever a nova maneira de demonstrar / testar os benefícios (Nenhum de nós usou o SSIS, portanto haveria um período em que tem que aprender a usá-lo).

O que devo fazer nesta situação? Pare de empurrar a nova tecnologia? Espere até ele sair do departamento (eu sou a segunda pessoa mais Sr. no departamento depois dele, mas pode levar anos até que ele desista / se aposente)? Encontrou uma nova maneira de fazê-lo parar de ter medo de ferramentas de terceiros?

Eu recomendo que você aprenda o SSIS o suficiente para poder demonstrar seus benefícios.

E se, após seu auto-estudo, você achar que o SSIS oferece vantagens significativas em relação à abordagem mais "tradicional" e ainda não conseguir convencer seu chefe a mudar de rumo, recomendo que encontre um trabalho diferente no qual possa use SSIS.

Jim G.
fonte
4
Além de não ser compatível com o controle de origem, o SSIS ainda não possui funções definidas pelo usuário , apesar de ser de longe o recurso mais solicitado no Microsoft Connect por muitos anos. Por esse motivo, as soluções SSIS tendem a ser desleixadas e com o código copiado em todo o lugar. Mais do que provável, implementar qualquer lógica não trivial do C # no SSIS tornaria o código muito menos limpo e muito mais difícil de manter.
BlueRaja - Danny Pflughoeft 18/01
11

A resposta que você quase sempre faz da maioria dos tipos de gerente é algo como:

"Não vale a pena, funciona agora e vai custar tempo para mudar".

E, em geral, isso é válido. No entanto, esse nem sempre é um argumento válido, porque o principal problema em torno da síndrome "Não foi inventado aqui" não é se as coisas funcionam ou não, mas essa tecnologia está sendo reescrita sem sentido , desperdiçando horas da empresa e prejudicando um valor substancial do produto que está sendo entregue.

Você precisa determinar se Não está inventado aqui realmente está ocorrendo antes de decidir o que fazer. A tecnologia interna pode ter sido escrita por uma razão .

Sinais de que a tecnologia foi reescrita por um motivo:

  • A tecnologia que você está vendendo também é o produto . Se você é um fornecedor de banco de dados, usando o código MySQL, não importa quanto tempo economize, é uma ideia perigosa por vários motivos.
  • A tecnologia interna é bem mantida e soluciona efetivamente as deficiências da solução pronta para uso, além de fornecer funcionalidade básica comparável.
  • A tecnologia melhora a produtividade de toda a equipe de desenvolvimento, e novos desenvolvedores são facilmente vendidos por que estão em uso.
  • Existem outros exemplos em que a empresa adotou com sucesso outras tecnologias externas .
  • Sua empresa seria imediatamente e seriamente afetada se a solução OTS fosse descontinuada ou interrompida.
  • A empresa é tão grande que possui recursos para gravar ferramentas de alta qualidade a baixo custo (por exemplo, o Google pode escrever um banco de dados que custa menos de uma licença MS SQL de US $ 1000 / assento)

Em outras palavras, a equipe entende as desvantagens de resolver problemas já resolvidos, mas criteriosamente fez exceções onde fazia sentido da perspectiva dos negócios.

Sinais de "não inventado aqui":

  • Parece que tudo é interno e há desculpas para tudo: "foi muito lento", "é a Microsoft, odiamos a Microsoft", "parece muito difícil de usar" etc.
  • Nos casos em que a tecnologia externa está sendo usada, você ouve "sim, bem, fede e planejamos escrever nossa própria eventualmente ".
  • Os proprietários desses componentes não têm outros empregos nos quais possam trabalhar.
  • Você vê a maioria dos novos desenvolvedores chegando com um conjunto de habilidades amplamente aceito, mas leva um tempo considerável para eles se adaptarem às ferramentas internas
  • Após uma análise cuidadosa, torna-se aparente que alternar da solução OTS para uma solução personalizada ou outra solução OTS no "e se for descontinuado!" cenário teria um impacto mínimo nos negócios . Por exemplo, se String.Join()fossem removidos do .NET Framework, a reimplementação em um StringJoin()método personalizado seria trivial.

Em outras palavras, o NIH é o padrão de deixar de ser objetivo e realista nos casos em que a tecnologia externa está sendo usada em vez do próprio código.

Quando a tecnologia é reescrita por um motivo, as preocupações devem ser elogiadas e apreciadas pelos seus superiores. Deveria ter sido uma decisão cuidadosa quando a tecnologia foi implementada, e revisar a decisão ocasionalmente é bom para os negócios. As coisas mudam com o tempo e você pode ter um ponto válido. Se você pode fornecer números sobre o tempo perdido no passado, os custos projetados para alternar e outras informações, você pode (em teoria) defender a mudança.

Entenda que, dada a sua experiência, eles podem não concordar com seus números, mas, independentemente disso, devem pelo menos ouvi-lo. Pode levar tempo para ganhar respeito.

Se a conversa não puder ser iniciada, mesmo se você estiver sendo educado, pode ser apenas "Não inventado aqui". Nesse caso, é mais provável que seja uma questão política ou de personalidade que você provavelmente não consiga resolver facilmente. Trabalhar em um ambiente fortemente atolado pela reinvenção constante é tóxico para os desenvolvedores e os negócios. Corre.

(Observação: na maioria das empresas, sempre há um elemento do NIH, mas é em um nível tolerável, e desde que eles revisem regularmente seu código e práticas. A longo prazo, todos somos culpados até certo ponto, mas isso nunca se torna um problema.)

Kevin McCormick
fonte
4

Bem, é tudo sobre a análise de custo / benefício.

O que você ganha reescrevendo-o no SSIS? Rapidez? Isso importa? Se for um processo executado em uma GUI e desperdiçar o tempo de todos, é provável que seja uma boa idéia acelerá-la, porque o dinheiro gasto para mudá-la será recuperado por clientes mais satisfeitos ou por funcionários internos que fazem seu trabalho em vez de aguardando o software. Mas se é um lote noturno que começa às 12h e termina às 1h em vez das 6h ... não faz muito sentido. Sim, é 6 vezes mais rápido, mas ninguém sentirá a diferença.

E seu chefe tem um bom argumento. A Microsoft costuma abandonar algumas de suas tecnologias. VB6, Linq-to-SQL, ASP classic, COM + ... Esse é um risco com qualquer software de código não aberto (e software de código aberto que seria muito grande para a sua organização manter em caso de falta de atualização). Se for central para o seu aplicativo, você deve ter um controle rígido sobre ele.

O software tem tudo a ver com agregar valor ao cliente, e o aprimoramento técnico que não gera muitos benefícios ao mesmo tempo em que introduz riscos não cumpre esse papel.

Laurent Bourgault-Roy
fonte
2
Como o VB6 foi "abandonado"? Foi suportado por 10 anos, vários dos quais o caminho de atualização para o próximo idioma estava disponível. o abandono do Windows 3.1 também?
precisa
11
@ ChrisPitman - Pode-se salientar que os aplicativos VB6 ainda funcionam no Windows 8. Agora, se estamos falando de um aplicativo VB6 no Windows 8 de 64 bits tentando acessar um banco de dados, você pode ter problemas por outros motivos.
Ramhound 18/01
11
Bem, a título de comparação, em 2010, trabalhei em um aplicativo Windows C ++ que começou no início dos anos 90 na estação de trabalho Unix. Em algum momento eu estava abrindo um arquivo com comentários que datam de 1993 e o último commit em 2001. Ele ainda funciona hoje e é muito popular em seu nicho. Claro que eles atualizaram parte dele conforme as versões do Windows foram passando, mas isso é esperado. O que nunca aconteceu é de repente perceber que o milhão de linhas de código que eles tinham eram todas atualizadas para um novo idioma semelhante, mas não exatamente o mesmo. Eles nunca tiveram que reescrever tudo.
precisa
3

Desenvolva um POC (Proof of Concept) e depois demonstre-o ao seu superior. O POC deve ajudá-lo a determinar qualquer benefício real com a tecnologia que você está propondo. Então você e seu superior podem falar sobre a tecnologia e desenvolver prós e contras para implementá-la.

Você provavelmente terá que gastar algum tempo extra fora do tempo normal de trabalho para desenvolver o POC.

Como uma observação lateral do ponto de vista do SSIS, eu o usei e desenvolvi pacotes SSIS. Na verdade, substituímos um processo de carregamento proprietário usando pacotes SSIS. Só fizemos isso porque os clientes reais se queixaram dos tempos de carregamento. O tempo de carregamento diminuiu significativamente com o SSIS e todos ficaram mais felizes.

O SSIS é basicamente um fluxo de trabalho de arrastar e soltar com muito pouca programação envolvida. Leva algum tempo para aprender como a caixa preta funciona; portanto, você precisará levar isso em consideração se sua equipe começar a usá-la.

Jon Raynor
fonte
11
Ele deveria obter permissão do chefe para fazer um POC, e parece que ele não conseguiria. Se o fizer sem permissão, ele se arrisca a tentar explicar como passou seu tempo se o POC não for aceito.
Reactgular
@ Matthew - Bom ponto, talvez um fim de semana hack-a-thon, se ele está tão inclinado a fazer sem aprovação.
Jon Raynor
1

Boas respostas. Se não estiver quebrado, não conserte. Eu só adicionaria

  • Embora as preocupações com o desempenho possam realmente ser verdadeiras, essa palavra "pode" é uma bandeira vermelha. Eu faria o diagnóstico de desempenho primeiro, para ter provas de qual era o problema de desempenho, antes de comprometer qualquer recurso para resolvê-lo.

  • Ao considerar a mais recente "solução" da Microsoft, deve-se considerar que muitas pessoas foram queimadas pelo que a MS estava divulgando, mas que posteriormente foi reprovada e, em seguida, descomprometida. Se você deseja que o software funcione por 10 ou 20 anos sem grandes recodificações, tenha muito cuidado com isso. Nossa empresa foi gravemente ferida dessa maneira.

Mike Dunlavey
fonte
1

A rotatividade será uma consideração para o seu chefe. O SSIS está entrando na arena do DBA em comparação com um programador com esse conjunto de habilidades. Se o seu aplicativo não usa o SSIS além da conversão inicial, não tenho certeza se faz sentido aprendê-lo e acelerar novos programadores de C # porque, como sua equipe, a maioria não tem experiência com ele.

JeffO
fonte
1

Você pode indicar ao seu chefe que o SSIS é, de fato, uma camada de tecnologia mais antiga que o .NET Framework, se você voltar às suas raízes como o "Data Transformation Framework" do SQL 7.0.

O ponto em que seu chefe pode ter razão é que o SSIS é apenas uma parte das versões Standard e Enterprise do Microsoft Sql Server; é uma grande parte da mudança para seus clientes pagarem, quando seu aplicativo, em um cenário de pequenas empresas, pode estar perfeitamente bem com o Sql Express (ou MySQL, que funciona com o ADO.NET, mas não pode use a integração SSIS).

Agora, deixe-me ser perfeitamente claro; OMI, NIH quase nunca é uma coisa boa para uma casa de desenvolvimento de software. Ele impede você de muitas ferramentas e serviços muito poderosos. Também é hipócrita em seu rosto; sua empresa escreveu o Visual Studio? E o .NET Framework? Servidor SQL? Janelas? Não. Você constrói seu software sobre as ferramentas e plataformas que já possui (e seus clientes também). Portanto, se você encontrar uma ferramenta que está obtendo aceitação geral e que pode ser útil no desempenho do seu negócio principal, você a adota e aprende a viver com o risco de ter que manter sua implementação para acompanhar as atualizações mais recentes. versões dessas ferramentas, ou mesmo substituí-las. Aposto que seu chefe desenvolveu o software para rodar no Windows 95/98 ou nos próximos anos (se não muito tempo)antes disso, como 3.0 / 3.1). Nesse caso, ele viu meia dúzia de versões dos sistemas operacionais Windows chegar e sair, e teve que atualizar seu software para rodar nas plataformas mais novas, e ele está enfrentando outra com o XP oficialmente EOLed. Embora ele possa reclamar, esse é simplesmente o custo de fazer negócios.

No entanto, uma atitude do NIH não decorre necessariamente de uma recusa em aceitar uma, ou mesmo várias, tecnologias que podem ser vistas como úteis. Essas recusas podem ser baseadas em análises de custo-benefício perfeitamente válidas. Eu trabalho para uma empresa de vigilância por vídeo e monitoramento de alarmes e tomamos decisões para apoiar ou não o suporte diário de várias novas tecnologias ou produtos. Geralmente, a decisão de aceitar uma nova tecnologia e a dor de combiná-la com nosso monte de softwares de gerenciamento de visualizador e alarme suportados, são baseadas principalmente no que vale a pena para nossos clientes. Concluí recentemente um grande projeto de integração com um novo tipo de DVR, simplesmente porque um dos nossos maiores clientes existentes disse que estava atualizando para esse DVR a partir de outro produto DVR de grande nome, mas tecnologicamente deficiente, e eles fariam isso com ou sem a nossa ajuda. Por outro lado, regularmente rejeitamos novos fabricantes, mesmo os principais nomes familiares, simplesmente porque nossos clientes não o usam e não vemos valor em começar a oferecê-lo, mesmo que nos perca alguns clientes em potencial que o possuem e não o fazem ' Não quero pagar por nossa versão da mesma coisa.

KeithS
fonte
0

Não tenho tempo para escrever a conversão da maneira antiga, autodidata do SSIS e também escrever a nova maneira de demonstrar / testar os benefícios (Nenhum de nós usou o SSIS, portanto haveria um período em que tem que aprender a usá-lo).

Esse é o tipo de problema, não é? Você está pedindo que outras pessoas arrisquem sua produtividade com a sua ideia e não está disposto a se esforçar para mostrar que vale a pena. A liderança técnica exige que você arrisque sua reputação ou tenha tempo livre para mostrar que vale a pena ter suas idéias.

Dan Monego
fonte
-1

Tente ver as coisas da perspectiva do seu chefe. Parece que a funcionalidade que você está tentando substituir é essencial para o que o seu software faz (consulte o comentário "ferrado"). Um bom gerente sabe que você terceiriza seu negócio principal por sua própria conta e risco. Ele está justamente preocupado em apostar na fazenda em algum tipo de tecnologia que possa desaparecer no futuro. Quando as funções principais estão envolvidas, não é inventado aqui é realmente uma coisa boa.

Se a velocidade é um recurso, você terá que encontrar outra maneira de acelerar as coisas. Caso contrário, se a velocidade é mais importante para você do que para seus clientes, digo: abandone e esqueça.

Kristo
fonte
3
Discordo. Se o NIH fosse bom para os resultados de qualquer empresa de desenvolvimento de software, essa pergunta nem teria a tag .net porque ninguém estaria disposto a "terceirizar" o controle dos recursos do computador e ficar preso em uma caixa de areia. Se isso é realmente uma preocupação legítima para o chefe do OP, o OP estaria programando em C ++ nos MFCs e no tempo de execução Win32 nativo. Um estado de coisas válido, com certeza, mas a disposição do chefe em aceitar novas tecnologias é desmentida por sua aceitação inata de outra tecnologia relativamente nova (o .NET é mais novo que o SSIS em geral)
KeithS
-1

Embora haja mérito de “não consertar o que não está quebrado”, discordo da resposta aceita.

A resposta aceita vem da perspectiva de que o problema não está quebrado. Do ponto de vista da gerência de nível médio, isso é verdade. Se uma análise de custo fosse feita no tempo gasto pelos desenvolvedores para criar e manter uma solução ETL em C # em comparação com a compra de uma solução pronta para uso, mostraria que a solução C # leva de 3 a 4 vezes mais para criar e manter e custar até 10 vezes mais (procurei a referência nos números, mas não a encontrei).

A menos que seja a principal competência da empresa, há muito pouco motivo para gravar e manter transformações de dados em C #. A solução doméstica será lenta, haverá erros (ou seja, dados corrompidos), haverá casos extremos, haverá pouca reutilização entre as classes ETL e será frágil. Honestamente, qual desenvolvedor deseja passar seus dias escrevendo e mantendo ETL em C #? Eu fiz isso. É um monte de porcaria. É o mais longe possível do trabalho criativo.

Use uma ferramenta como a Informatica, uma empresa cuja empresa é ETL. Eles estão trabalhando nesse problema há mais de 15 anos. Eles o resolveram. Suas ferramentas são arrastar e soltar, a reutilização é incorporada, assim como o desempenho. Quase todo mundo (ou seja, os desenvolvedores também não têm) pode criar ETL com as ferramentas da Informatica. Não estou tentando vender a Informatica, use qualquer ferramenta. Só não reinvente a roda.

A longo prazo, a compra de uma ferramenta, como a Informatica ou o uso do SSIS, economizará à empresa potencialmente milhões a longo prazo. E o melhor de tudo é que você não precisará manter o ETL ou ser responsável por ele quando ele quebrar.

Chuck Conway
fonte
-3

Eu tentei o SSIS para executar tarefas simples antes.

Pode ser muito chato, pois mesmo tarefas simples dão origem a diagramas de complexidade de baixo a médio nível (não, não há outra maneira de "codificá-lo", exceto os diagramas). E os problemas de controle de origem apontados pela resposta de Jim não estavam cientes.

Problema secundário: para acelerar, sugiro reduzir o tamanho das transações dos seus volumes de imagem. Digamos, a cada 800 em vez de 5000 rocords. Pode reduzir o tamanho da E / S necessária para suportar essa transação.

Fabricio Araujo
fonte
11
Enviar 800 em vez de 5000 pioraria as coisas; você ainda tem que enviar a mesma quantidade exata de dados reais, mas agora você tem chamadas rede mais o que significa mais cabeçalhos dos pacotes, etc.
Andy
A E / S normalmente custa muito mais que a rede. Mesmo usando cópias em massa, há coisas que são registradas. Muita E / S ao mesmo tempo fará com que a CPU fique com pouco uso e paralise o servidor até que a E / S seja concluída. Obviamente, isso depende de quão poderoso é o subsistema de E / S desses servidores de banco de dados.
Fabricio Araujo 21/01
Faça seus próprios testes; você verá que o lote é mais rápido do que enviar cada extrato separadamente.
Andy
Eu fiz no passado e às vezes tive que reduzir o tamanho dos lotes para ficar mais rápido. É uma coisa de sintonia.
Fabricio Araujo 21/01