¿Qué tan común es que un equipo escriba todo en casa? [cerrado]

Una actitud de nunca utilizando bibliotecas de terceros es absurda. Escribir todo usted mismo es un uso horrible del tiempo de su empresa, a menos que exista un requisito comercial estricto de que cada línea en el código base haya sido escrita por un empleado de la empresa, pero ese es un escenario inusual, especialmente para una empresa del sector privado como usted ha descrito.

Una respuesta más racional y completa puede haber sido que solo usarían bibliotecas de terceros que:

• Satisfacer las necesidades del código que de otro modo se escribirían ellos mismos
• Estaban disponibles bajo una licencia compatible con el modelo de negocios de la compañía
• pruebas incluidas
• aprobó una revisión del código

Si se cumplieron esos criterios (y, según mi experiencia, la revisión del código es muy flexible, especialmente en presencia de buenas pruebas), ya no se "confía en nadie más", se confía en los existentes, disponibles, y preferiblemente código robusto.

Si el código es de código abierto, en el peor de los casos, la biblioteca de terceros quedará sin mantenimiento. ¿Pero a quién le importa? ¡Las pruebas demuestran que la biblioteca es adecuada para sus necesidades!

Además, una aversión a las bibliotecas de terceros establecidas dificulta seriamente la productividad del programador. Digamos que la compañía estaba escribiendo aplicaciones web y se negó a usar (por ejemplo) jQuery, así que en lugar de eso, escribieron su propia biblioteca alternativa entre navegadores para simplificar la manipulación de DOM. Con casi certeza podemos asumir que su implementación:

• Tendrá una API ajena a los desarrolladores ya familiarizados con jQuery
• No estará tan bien documentado como jQuery
• No tendrá resultados relevantes de Google cuando tenga problemas al utilizar la biblioteca
• No será tan probado en el campo como jQuery

Todos esos puntos son barreras importantes para la productividad del programador. ¿Cómo puede una empresa permitirse renunciar a una productividad como esa?

Ha actualizado su pregunta para preguntar si esto es apropiado para una segunda entrevista. Absolutamente lo es.

Tal vez usted malinterpretó la respuesta de su entrevistador en la primera entrevista, o tal vez el entrevistador simplemente explicó incorrectamente la posición de la compañía y un nuevo entrevistador puede aclararlo.

Si explica que le preocupa su postura en bibliotecas externas, hay al menos dos resultados posibles:

• Están abiertos al cambio, y su preocupación por su proceso lo hace lucir mejor que otros candidatos.
• No están abiertos al cambio, y te consideran "el tipo de desarrollador que no querríamos contratar". No importa, ese no es el tipo de lugar donde quieres trabajar de todos modos.

Eso parece increíblemente poco competitivo. He trabajado en tiendas que decidieron omitir las bibliotecas estándar de código abierto como Hibernate y rodar las suyas debido a que faltaba alguna característica "crítica". Al final, el software era increíblemente caro de construir y mantener. Por supuesto, el costo de la biblioteca interna fue subestimado. Y mientras se escribía la biblioteca interna, las bibliotecas estándar avanzaban rápidamente, agregando nuevas funciones que no estaban disponibles en la biblioteca interna. Al final, el trabajo que llevaría una hora usando una biblioteca estándar demoró dos días. Y fue malo para las carreras del desarrollador, a medida que el mundo los pasaba. Yo evitaría una tienda como esa. Me gusta entregar, y no tengo la paciencia para volver a escribir cuando podría reutilizarlo.

La tienda tiene una enfermedad llamada No está inventado aquí . Es una buena razón para terminar la entrevista en el lugar y salir inmediatamente. Esto solo puede ser curado por una limpieza de la casa de arriba a abajo que es muy poco probable que ocurra.

Para responder a tu pregunta, lamentablemente es mucho más común de lo que piensas y definitivamente es una razón para preocuparse.

¡Sí, definitivamente preocupate! Eso apesta a la arrogancia y (lamento ser cruel) estupidez. Cualquier programador con medio cerebro utilizará una biblioteca como signalR en lugar de escribirla usted mismo. No tiene ningún sentido perder el tiempo resolviendo un problema que ya se ha resuelto. Posiblemente trataría de encontrar más información primero, podrían haberte entendido mal (aunque podría ser difícil si las entrevistas hubieran terminado)

Tengo un par de amigos que han trabajado (brevemente) en software con el síndrome que no se ha inventado aquí . Así que la mentalidad está ahí fuera.

Una observación que ambos hicieron fue en torno a la cultura que fomentó el enfoque en los equipos de desarrollo. Ambos terminaron trabajando con personas que eran bastante insulares en cuanto a su perspectiva sobre el desarrollo de software, y personas que no estaban realmente motivadas para aprender cosas nuevas e impulsar la calidad. Independientemente de la etapa en la que se encuentre en su carrera, siempre le gustaría trabajar en algún lugar donde tenga la oportunidad de aprender cosas nuevas de sus compañeros. Sin embargo, parece que este tipo de entorno generalmente no se encuentra en lugares que desean rodar todo por sí mismos.

No es común donde vivo, y conozco a muchas compañías a través de colegas. Iría tan lejos para decir que es un "no gracias" inmediato de mi parte.

No regurgitaré los buenos puntos ya hechos, pero agregaré una cosa.

Acaban de hacer mucho más difícil la contratación.

• Todas las nuevas contrataciones tienen una curva de aprendizaje aún más pronunciada que solo la parte principal del software / dominio
• Se postergarán los mejores candidatos, ya que no querrán que sus habilidades queden sin uso.
• Es probable que las personas no se queden mucho tiempo una vez que se den cuenta de lo malo que es no poder utilizar sus herramientas favoritas, y la rotación de personal es costosa

Ahora, por supuesto, habrá personas a las que les guste el desafío, pero creo que estarían en la minoría.

E igualmente, habrá algunas compañías que operan en "escala de Internet", Amazon, Facebook, etc., donde tienen necesidades personalizadas, pero nuevamente estas son minorías.

No creo que una empresa de software pueda sobrevivir hoy sin depender de un software de código abierto o de terceros, y para mantenerse competitivos, por supuesto, necesitan realizar un seguimiento activo de las nuevas tecnologías. Sin embargo, a menudo hay buenas razones para tener al menos una visión defensiva al respecto.

Como ejemplo, si vende software y afirma proporcionar soporte 24/7 y también es legalmente responsable de que su software funcione correctamente, debe tener una idea muy precisa de lo que va a suceder si hay una un problema con su software en, por ejemplo, una fábrica donde 1 hora de inactividad de producción puede costar varios millones de dólares, y luego ocurre un error grave en la biblioteca de código abierto que estaba usando. Créeme, realizará evaluaciones muy completas del software en cuestión.

Por lo que has escrito, este escenario no parece estar en el centro del asunto, sin embargo.

Si usted es una empresa basada en tecnología de un tamaño determinado, parece que desarrollará cada vez más su propia tecnología, por ejemplo: Google desarrolla mucho si no la mayoría si no todo su software mientras está abierto. la mayor parte en la búsqueda para convertirla en un estándar de la industria.

Para las empresas más pequeñas, parecería una pérdida total de tiempo cuando intentan enviar un producto específico con su propia lógica de negocios, y según mi experiencia, no he visto que las pequeñas y medianas empresas lo hagan.

Se vuelve más complejo cuando se habla de una base de código muy especializada, por ejemplo: algoritmos de encriptación: algunas personas tienen un conocimiento básico de cómo funcionan, pero las partes complejas de implementar una solución realmente parecen dispararse en el pie, a menos que contrates a un criptógrafo que se especialice en tales cosas.

Algunas empresas sí permiten la libertad de crear sus propios proyectos de código abierto, lo que parece más apropiado.

Yo personalmente no iría a un lugar con tal cultura.

Lo que tienes es una muy buena oportunidad para ir a la segunda entrevista y hacerles algunas preguntas difíciles. No sé qué hace la empresa, por lo que es difícil decir por qué esto parece una elección extraña. Puede usar el comentario de @Daniel Pryden con respecto al uso de Google de bibliotecas de terceros.

Cualquier pieza de software que utilice, ya sea de forma interna o de terceros, tiene ventajas y desventajas. No usar una herramienta porque no es interna, incluso si es la mejor herramienta para el trabajo, muestra cierta mentalidad cerrada y eso nunca fomentará la innovación y la creatividad.

Aunque quizás, solo quizás, eres la persona para introducir ese cambio. Buena suerte con todo.

Por supuesto que debes alejarte. No lo he visto mencionado aquí, pero la razón más importante para pasar por alto el trabajo es porque no ganarás mucho en habilidades transferibles.

Imagínate en tu próxima entrevista cuando te preguntan con qué tecnologías trabajaste y solo puedes mencionar C ++. Eso suena como un nivel de posgrado

Las grandes empresas escriben todo ellos mismos.

Hay varias ventajas al escribirlo usted mismo:

1. Tienes la garantía de ser el propietario del software
2. Puedes calcular correctamente las cantidades de trabajo que se crearon para crearlo
3. Repetir tus pasos es posible incluso si la próxima vez que las librerías no estén disponibles
4. Reduce la cantidad de requisitos necesarios
5. No estás repitiendo lo que otros ya han hecho
6. Se te garantiza que tienes suficientes personas para mantenerlo
7. Puede modificar cada parte del software
8. El tamaño del software está limitado por la cantidad de recursos que tiene

Aquí se explica cómo se rompe cada uno de los puntos si usas la biblioteca de alguien más:

1. Alguien más es el propietario de la lib
2. No sabes cuánto esfuerzo se dedicó a crear la biblioteca
3. Es imposible crear su próxima versión de producto en una nueva plataforma, ya que las mismas bibliotecas ya no están disponibles
4. La capacidad para implementar el requisito depende de si la biblioteca lo implementó hace años
5. Alguien más también usa la misma biblioteca, obteniendo las mismas limitaciones y características
6. Como no creó las librerías, no tiene suficientes personas para mantener todo el software en su producto
7. Las bibliotecas son binarias, no modificables. Incluso si la fuente está disponible, no tienes suficientes personas para modificar esa gran cantidad de código.
8. Mantener el código que creó + las bibliotecas es un esfuerzo mayor del que originalmente estimó