Quão comum é que uma equipe escreva tudo internamente? [fechadas]

Em uma entrevista recente, perguntei aos entrevistadores "como você avalia novas tecnologias e bibliotecas (como o SignalR) e as coloca em uso?". Eles disseram que não, que em vez disso escrevem tudo sozinhos para não precisar confiar em mais ninguém.

A empresa não trabalha para o governo ou empreiteiros de defesa ou em nenhum projeto crítico de segurança ou algo assim. Eles eram apenas sua empresa de desenvolvimento de software de tamanho médio.

Minha pergunta é: quão comum é que as equipes escrevam tudo sozinhas? Devo me preocupar com as equipes que o fazem?

Editar - Quase todas as respostas disseram que isso é algo para se preocupar. Uma segunda entrevista seria um momento apropriado para pedir que eles esclarecessem / repetissem sua posição ao escrever tudo internamente?

Uma atitude de nunca usar bibliotecas de terceiros é absurda. Escrever tudo você mesmo é um uso horrível do tempo da sua empresa, a menos que exista um requisito comercial rigoroso de que cada linha da base de código tenha sido escrita por um funcionário da empresa - mas esse é um cenário incomum, especialmente para uma empresa do setor privado como você descreveu.

Uma resposta mais racional e completa pode ter sido que eles usariam apenas bibliotecas de terceiros que:

• Atender às necessidades do código que eles mesmos escreveriam
• Estavam disponíveis sob uma licença compatível com o modelo de negócios da empresa
• Testes incluídos
• Aprovado na revisão de código

Se esses critérios foram atendidos (e, na minha experiência, a revisão de código é muito flexível, especialmente na presença de bons testes), você não está mais "confiando em mais ninguém" - está confiando nos existentes, disponíveis e de preferência robustos código.

Se o código for de código aberto, na pior das hipóteses, a biblioteca de terceiros ficará sem manutenção. Mas quem se importa? Os testes provam que a biblioteca é adequada às suas necessidades!

Além disso, uma aversão a bibliotecas estabelecidas de terceiros dificulta seriamente a produtividade do programador. Digamos que a empresa estava escrevendo aplicativos da Web e se recusou a usar (por exemplo) jQuery, então, em vez disso, escreveu sua própria biblioteca alternativa entre navegadores para simplificar a manipulação do DOM. Com quase certeza, podemos assumir que sua implementação:

• Terá uma API estrangeira para desenvolvedores já familiarizados com o jQuery
• Não será tão bem documentado quanto o jQuery
• Não terá resultados relevantes do Google ao encontrar problemas ao usar a biblioteca
• Não será tão testado em campo quanto o jQuery

Todos esses pontos são grandes barreiras à produtividade do programador. Como uma empresa pode se dar ao luxo de desistir dessa produtividade?

Você atualizou sua pergunta para perguntar se isso é apropriado para iniciar em uma segunda entrevista. Absolutamente é.

Talvez você tenha interpretado mal a resposta do entrevistador na primeira entrevista, ou talvez o entrevistador tenha explicado incorretamente a posição da empresa e um novo entrevistador possa esclarecê-la.

Se você explicar que está preocupado com a posição deles em bibliotecas externas, há pelo menos dois resultados possíveis:

• Eles estão abertos a mudanças, e sua preocupação com o processo deles faz com que você pareça melhor do que alguns outros candidatos.
• Eles não estão abertos a mudanças e pensam em você como "o tipo de desenvolvedor que não queremos contratar". Não importa, esse não é o tipo de lugar em que você deseja trabalhar.

Isso parece incrivelmente pouco competitivo. Eu trabalhei em lojas que decidiram pular as bibliotecas padrão de código aberto, como o Hibernate, e criar suas próprias devido a algum recurso ausente "crítico". No final, o software era incrivelmente caro para construir e manter. É claro que as despesas da biblioteca interna foram subestimadas. E enquanto a biblioteca interna foi gravada, as bibliotecas padrão avançaram rapidamente, adicionando novos recursos que não estavam disponíveis na biblioteca interna. No final, o trabalho que levaria uma hora usando uma biblioteca padrão levou dois dias. E isso foi ruim para as carreiras do desenvolvedor, à medida que o mundo passava por elas. Eu evitaria uma loja assim. Gosto de entregar e não tenho paciência para reescrever quando poderia reutilizá-lo.

A loja tem uma doença chamada Não inventada aqui . É um bom motivo para encerrar a entrevista no local e sair imediatamente. Isso só pode ser curado com uma limpeza de cima para baixo que é muito improvável.

Para responder sua pergunta, infelizmente é muito mais comum do que você imagina e é definitivamente um motivo para se preocupar.

Sim, definitivamente se preocupe! Isso cheira a arrogância e (desculpe por ser duro) estupidez. Qualquer programador com meio cérebro usará uma biblioteca como signalR em vez de escrever você mesmo. Não faz sentido perder tempo resolvendo um problema que já foi resolvido. Eu provavelmente tentaria descobrir mais informações primeiro - eles podem ter entendido mal você (pode ser difícil, se as entrevistas terminarem!)

Tenho alguns amigos que trabalharam (brevemente) em casas de software com a síndrome não inventada aqui . Então a mentalidade está lá fora.

Uma observação que ambos fizeram foi em torno da cultura, a abordagem promovida nas equipes de desenvolvimento. Os dois acabaram trabalhando com pessoas que eram bastante insulares em termos de perspectivas sobre o desenvolvimento de software e pessoas que não eram realmente motivadas a aprender coisas novas e buscar qualidade. Independentemente do estágio em que está na sua carreira, você sempre gostaria de trabalhar em algum lugar em que tenha a chance de aprender coisas novas de seus colegas. Entretanto, esse tipo de ambiente geralmente não é encontrado em lugares que desejam rolar tudo por conta própria.

Não é comum onde eu moro, e conheço muitas empresas através de colegas. Eu diria que é um imediato "não, obrigado" de mim.

Não vou regurgitar os bons pontos já apresentados, mas vou acrescentar uma coisa.

Eles acabaram de tornar a contratação muito mais difícil.

• Todas as novas contratações têm uma curva de aprendizado ainda mais acentuada do que apenas a parte principal do software / domínio
• Os melhores candidatos serão adiados, pois não desejam que suas habilidades não sejam utilizadas.
• Não é provável que as pessoas permaneçam por muito tempo depois que percebem o quão ruim não está usando suas ferramentas favoritas, e a rotatividade de funcionários é cara

Agora, é claro, haverá pessoas que gostarão do desafio, mas acho que elas seriam minoria.

E, igualmente, haverá algumas empresas que operam em "escala da Internet", Amazon, Facebook, etc., onde elas têm necessidades personalizadas insanas, mas, novamente, são minoria.

Não acho que uma empresa de software possa sobreviver hoje sem depender de software de terceiros e / ou de código aberto e, para permanecerem competitivas, é claro que precisam acompanhar ativamente as novas tecnologias. Muitas vezes, existem boas razões para adotar pelo menos uma visão bastante defensiva.

Por exemplo, se você vende software e pretende fornecer suporte 24 horas por dia, 7 dias por semana, e também é legalmente responsável por seu software funcionar corretamente, é necessário ter uma idéia muito precisa do que acontecerá se houver um problema com o seu software. software em, digamos, uma fábrica onde 1 hora de inatividade da produção pode custar vários milhões de dólares e, em seguida, ocorre um bug sério na biblioteca de código aberto que você estava usando. Acredite, você realizará avaliações muito completas do software em questão.

Pelo que você escreveu, esse cenário não parece estar no cerne da questão.

Se você é uma empresa de base tecnológica de um determinado tamanho, parece que estará desenvolvendo cada vez mais sua própria tecnologia, por exemplo: o google desenvolve muito, se não a maioria, se não todo o software, enquanto o código aberto é a maioria. na busca de torná-lo um padrão da indústria.

Para empresas menores, parece um desperdício de tempo total quando eles tentam enviar um produto específico com sua própria lógica de negócios e, na minha experiência, não vi que empresas de pequeno e médio porte o façam.

Torna-se mais complicado quando você está falando sobre uma base de código altamente especializada, por exemplo: algoritmos de criptografia - algumas pessoas têm um entendimento básico de como funcionam, mas as partes complexas da implementação de uma solução parecem parecer um tiro no pé a menos que você contrate um criptógrafo especializado em tais coisas.

Algumas empresas permitem a liberdade de criar seus próprios projetos de código aberto, o que parece mais apropriado.

Eu pessoalmente não iria a um lugar com essa cultura.

O que você tem é uma boa oportunidade para entrar na segunda entrevista e fazer algumas perguntas difíceis. Não sei o que a empresa faz, por isso é difícil dizer por que isso parece uma escolha estranha. Você pode usar o comentário de @Daniel Pryden no que diz respeito ao uso de bibliotecas de terceiros pelo Google.

Qualquer software que você usa, seja interno ou de terceiros, tem vantagens e desvantagens. Não usar uma ferramenta porque ela não é interna, mesmo que seja a melhor ferramenta para o trabalho que mostre uma certa mentalidade fechada e que nunca incentive a inovação e a criatividade.

Talvez, talvez, você seja a pessoa a introduzir essa mudança. Boa sorte com tudo.

Claro que você deve ir embora. Eu não vi isso mencionado aqui, mas o maior motivo para deixar o cargo de lado é porque você não ganhará muito em habilidades transferíveis.

Imagine na sua próxima entrevista quando eles perguntarem com quais tecnologias você trabalhou e você só pode mencionar C ++ básico. Isso soa como um nível de graduação

As grandes empresas escrevem tudo sozinhas.

Existem várias vantagens em escrever você mesmo:

1. Você tem a garantia de possuir o software por conta própria
2. Você pode calcular corretamente as quantidades de trabalho que foram criadas para criá-lo
3. Repetir suas etapas se torna possível, mesmo que da próxima vez as bibliotecas não estejam disponíveis
4. Reduz o inchaço das suas necessidades
5. Você não está repetindo o que os outros já fizeram
6. Você tem a garantia de ter pessoas suficientes para mantê-lo
7. Você pode modificar todas as partes do software
8. O tamanho do software é limitado pela quantidade de recursos que você possui

Veja como cada um dos pontos se quebra se você usar a biblioteca de outra pessoa:

1. Outra pessoa é dona da lib
2. Você não sabe quanto esforço foi necessário para criar a biblioteca
3. É impossível criar sua próxima versão do produto na nova plataforma, pois as mesmas bibliotecas não estão mais disponíveis
4. A capacidade de implementar o requisito depende de a lib ter implementado anos atrás
5. Outra pessoa também usa a mesma lib, obtendo as mesmas limitações e recursos
6. Como você não criou as bibliotecas, não há pessoas suficientes para manter todo o software do seu produto
7. Libs são binários, não modificáveis. Mesmo se a fonte estiver disponível, você não terá pessoas suficientes para modificar essa grande quantidade de código.
8. Manter o código que você criou + as bibliotecas é um esforço maior do que o estimado originalmente