Charlie, arquitecto senior de una organización de desarrollo de software de tamaño mediano, estaba sentado en su escritorio repasando las especificaciones del último proyecto de desarrollo de su empresa. Mientras analizaba de alto nivel cómo desglosar el trabajo para la primera fase del proyecto, Janice, una desarrolladora trabajadora que recién iniciaba su carrera, entró en su oficina.
Janice no duda. “Oye, veo que nuestro nuevo proyecto requerirá algo de cifrado. Me gustaría intentar escribir la biblioteca de cifrado para el proyecto. He estado analizando varios algoritmos últimamente y me gustaría intentarlo”.
Charlie, por supuesto, admira el entusiasmo, pero sabe de inmediato que esto no va a suceder.
“Janice, gracias por la oferta, pero te voy a decir un rotundo no. Y he aquí por qué: el cifrado es realmente difícil. El cifrado está plagado de peligros. El cifrado atrae a todo tipo de malos actores que intentarán descifrar lo que sea que estemos protegiendo. Cualquier agujero, cualquier error, cualquier problema podría exponernos a enormes riesgos de seguridad”.
“Está bien, entonces ¿por qué no puedo hacerlo? ¡Estoy a la altura del desafío!”
“Bueno, con el debido respeto, no lo eres. Joder, ni siquiera estoy cerca de estar a la altura. De hecho, muy pocos desarrolladores lo son. Mira, el cifrado es una de esas cosas que absolutamente debes dejar en manos de los expertos que han creado soluciones de código abierto públicas, bien examinadas y probadas en batalla. El cifrado es algo que debe funcionar perfectamente, o al menos tan cerca de la perfección como los verdaderos expertos pueden hacerlo. Los malos son igual de inteligentes y capaces, y las soluciones probadas son el único camino a seguir”.
«Mmm. Bien, supongo que eso tiene sentido. Pero sigo pensando que sería divertido hacerlo”, dijo Janice con una sonrisa mientras salía.
Pero el entusiasmo de Janice inspiró a Charlie y se le ocurrió una idea. Caminó hasta la oficina de su jefe y se sentó. Ella lo miró y dijo: «¿Qué pasa?»
“Allison, ya no puedo hacer mucha codificación nueva, así que personalmente quiero construir el sistema de cola de mensajes para nuestro nuevo proyecto. Sé que la clásica cuestión de ‘construir versus comprar’ siempre es una decisión difícil, pero me encantaría asumirla». Charlie se sentía bastante bien con la idea.
Allison se recostó por un momento y lo miró con una leve sonrisa. “Sé cómo te sientes, Charlie. Sería divertido. Pero voy a decirte un rotundo no a eso”.
Charlie sonrió interiormente ante la ironía.
“Mira, sé que eres bueno, pero incluso tú tendrás que admitir que no eres tan bueno. La cola de mensajes es compleja. Hacerlo bien es difícil, y optimizar esa corrección lo es aún más. Existe una gran cantidad de colas de mensajes completamente funcionales, completas, funcionales y probadas en el mundo del código abierto. Claro, probablemente conseguirás que algo funcione, pero aquí no somos expertos en colas de mensajes. Tomaría mucho, mucho tiempo asegurarnos de que cubra toda la superficie de los requisitos, e incluso entonces, no estaríamos completamente seguros”.
Charlie asintió con la cabeza con complicidad, admitiendo para sí mismo que ella tenía razón.
“Y luego, cuando se encuentra un error, tenemos que solucionarlo. Eso es caro. Y las incógnitas de hacerlo son, bueno, desconocidas, ¿verdad? Si optamos por Kafka o RabbitMQ o una solución comercial, sabemos que funcionará bien la primera vez. Solucionarán errores y detendrán las filtraciones incluso antes de que sepamos que están ahí. Preferiría que dedicaras tu tiempo a trabajar en lo más profundo de nuestra aplicación. Ha estado aquí 14 años y conoce nuestro negocio y nuestro código base al dedillo. Sé que te encantaría hacerlo, pero no puedo dejar que te tomes ese tiempo. Y creo que incluso usted admitiría que el riesgo y los costos posteriores son simplemente demasiados”.
Charlie suspiró. «Mmm. Bien, supongo que eso tiene sentido. Pero sigo pensando que sería divertido hacerlo”.
No puedes culpar a Charlie y Janice. Todo el mundo quiere trabajar en proyectos desafiantes que amplíen sus horizontes. Y es tentador pensar que son más inteligentes y pueden hacer un mejor trabajo que alguna empresa con una solución SaaS genérica. Sin embargo, la programación impulsada por el ego rara vez termina bien.
Incluso una suscripción costosa a una solución escrita por un equipo que conoce el dominio del problema por dentro y por fuera y que tiene la competencia central y la motivación para proporcionar una solución completa casi siempre costará menos a largo plazo que el costo desconocido de construir y manteniendo su propia solución.
A menos que exista una razón muy convincente para crear su propia solución y haya realizado la diligencia debida para asegurarse de que las soluciones disponibles realmente no se ajusten a sus necesidades, la decisión de crear y no comprar seguramente se convertirá en un revuelo inesperado. en el tanque de inmersión.
Copyright © 2024 IDG Communications, Inc.