¿Qué tan común es para un equipo escribir todo internamente? [cerrado]

En una entrevista reciente, le pregunté a los entrevistadores "¿cómo evalúa las nuevas tecnologías y bibliotecas (como SignalR) y las pone en práctica?". Dijeron que no, que en su lugar escriben todo ellos mismos para no tener que depender de nadie más.

La empresa no trabaja para el gobierno o los contratistas de defensa ni en ningún proyecto crítico para la seguridad ni nada de eso. Eran solo una empresa promedio de desarrollo de software de tamaño mediano.

Mi pregunta es: ¿qué tan común es que los equipos escriban todo ellos mismos? ¿Debería preocuparme los equipos que lo hacen?

Editar: la mayoría de las respuestas han dicho que esto es algo de lo que preocuparse. ¿Sería una segunda entrevista un momento apropiado para pedirles que aclaren / repitan su posición al escribir todo en casa?

Una actitud de nunca usar 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 de la base de código haya sido escrita por un empleado de la empresa, pero ese es un escenario inusual, especialmente para una empresa del sector privado como has descrito

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

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

Si se cumplieron esos criterios (y en mi experiencia, la revisión del código es muy flexible, especialmente en presencia de buenas pruebas), ya no está "confiando en nadie más", sino en los existentes, disponibles y preferiblemente robustos. código.

Si el código es de código abierto, en el peor de los casos, la biblioteca de terceros queda 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, por lo que escribió su propia biblioteca alternativa de navegador cruzado para simplificar la manipulación del DOM. Con casi certeza podemos suponer que su implementación:

• Tendrá una API ajena a los desarrolladores que ya están familiarizados con jQuery
• No estará tan bien documentado como jQuery
• No tendrá resultados relevantes de Google cuando encuentre problemas al usar 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 darse el lujo de renunciar a una productividad como esa?

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

Tal vez malinterpretaste la respuesta de tu 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 posición en las bibliotecas externas, hay al menos dos resultados posibles:

• Están abiertos al cambio, y su preocupación por su proceso lo hace ver mejor que otros candidatos.
• No están abiertos al cambio y piensan en usted como "el tipo de desarrollador que no queremos contratar". No importa, de todos modos ese no es el tipo de lugar donde quieres trabajar.

Eso parece increíblemente poco competitivo. He trabajado en tiendas que decidieron omitir las bibliotecas de código abierto estándar como Hibernate y rodar las suyas propias debido a alguna característica faltante "crítica". Al final, el software fue increíblemente costoso de construir y mantener. Por supuesto, los gastos de la biblioteca interna se subestimaron enormemente. Y aunque se escribió la biblioteca interna, las bibliotecas estándar avanzaron rápidamente, agregando nuevas características que no estaban disponibles en la biblioteca interna. Al final, el trabajo que tomaría una hora usando una biblioteca estándar en su lugar tomó dos días. Y fue malo para las carreras de los desarrolladores, ya que el mundo pasó de largo. Evitaría una tienda como esa. Me gusta entregar, y no tengo la paciencia para volver a escribir cuando podría reutilizar.

La tienda tiene una enfermedad llamada No inventado aquí . Es una buena razón para terminar la entrevista en el acto y partir de inmediato. Esto solo se puede curar con una limpieza de la casa de arriba hacia abajo que es muy poco probable que ocurra.

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

Sí, definitivamente, ¡preocúpate! Eso apesta a arrogancia y (perdón por ser duro) estupidez. Cualquier programador con medio cerebro usará una biblioteca como signalR en lugar de escribirlo usted mismo. No tiene sentido perder el tiempo resolviendo un problema que ya se ha resuelto. Posiblemente, primero trataría de encontrar más información; es posible que te hayan entendido mal (¡aunque podría ser difícil si las entrevistas han terminado!

Tengo un par de amigos que han trabajado (brevemente) en casas de software con el síndrome no inventado aquí . Entonces la mentalidad está ahí afuera.

Una observación que ambos hicieron fue en torno a la cultura que el enfoque fomentó en los equipos de desarrollo. Ambos terminaron trabajando con personas que eran bastante insulares en términos de su perspectiva sobre el desarrollo de software, y personas que realmente no estaban motivadas para aprender cosas nuevas y presionar por 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, este tipo de entorno generalmente no se encuentra en lugares que deseen rodar todo por sí mismos.

No es común donde vivo, y conozco muchas compañías a pesar de mis colegas. Me atrevería a decir que es un inmediato "no gracias" de mi parte.

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

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

• Todos los nuevos empleados tienen una curva de aprendizaje aún más pronunciada que solo la parte principal del software / dominio
• Los mejores candidatos se desanimarán, ya que no querrán que sus habilidades no se usen.
• No es probable que las personas se queden mucho tiempo una vez que se dan cuenta de lo malo que es no usar sus herramientas favoritas, y la rotación del personal es costosa

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

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

No creo que una compañía de software pueda sobrevivir hoy sin depender de un software de terceros y / o de código abierto, y para seguir siendo competitivas, por supuesto, necesitan realizar un seguimiento activo de las nuevas tecnologías. Sin embargo, a menudo hay buenas razones para adoptar al menos una visión bastante defensiva.

Como ejemplo, si vende software y afirma brindar asistencia las 24 horas, los 7 días de la semana y también es legalmente responsable de que su software funcione correctamente, entonces debe tener una idea muy precisa de lo que sucederá si hay 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 utilizando. Créame, realizará evaluaciones muy exhaustivas del software en cuestión.

Sin embargo, por lo que ha escrito, este escenario no parece ser el meollo del asunto.

Si usted es una empresa basada en tecnología de cierto tamaño, parece que va a 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 que la mayoría de ellos son de código abierto. en la búsqueda de convertirlo 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 en 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 altamente especializada, por ejemplo: algoritmos de cifrado: algunas personas tienen una comprensión básica de cómo funcionan, pero las partes complejas de implementar realmente una solución parecerían dispararse en el pie a menos que contrate a un criptógrafo especializado en tales cosas.

Algunas compañías permiten libertad para crear sus propios proyectos de código abierto, lo que parece más apropiado.

Yo personalmente no iría a un lugar con tanta 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 compañía, por lo que es difícil decir por qué 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 use, ya sea internamente o de un tercero, tiene ventajas y desventajas. No usar una herramienta porque no es interna, incluso si es la mejor herramienta para el trabajo muestra una cierta mentalidad cerrada y eso nunca fomentará la innovación y la creatividad.

Sin embargo, tal vez, solo tú eres la persona que introduce ese cambio. Buena suerte con todo.

Por supuesto que deberías alejarte. No lo he visto mencionado aquí, pero la razón más importante para dejar de lado el trabajo es porque no ganarás mucho en habilidades transferibles.

Imagínese en su próxima entrevista cuando le pregunten con qué tecnologías trabajó y solo puede mencionar C ++. Eso suena como un nivel de posgrado.

Las grandes empresas escriben todo por sí mismas.

Hay varias ventajas en escribirlo usted mismo:

1. Usted tiene la garantía de poseer el software usted mismo
2. Puede calcular correctamente las cantidades de trabajo que se utilizaron para crearlo
3. Es posible repetir sus pasos incluso si la próxima vez las bibliotecas no están disponibles
4. Reduce tu hinchazón requerida
5. No estás repitiendo lo que otros ya han hecho
6. Tienes garantizado tener suficientes personas para mantenerlo
7. Puedes modificar cada parte del software
8. El tamaño del software está limitado por la cantidad de recursos que tiene

Así es como se rompe cada uno de los puntos si usa la biblioteca de alguien más:

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