No es tarea fácil, pero en ITDO podríamos decir que somos políglotas en lo que refiere a tecnología, es por ello que intentaremos ayudarte en el camino. Pero a veces hay que evaluar y decidir que solución es la más adecuada para cada proyecto, la decisión es multidimensional y requiere una mirada desde muchas perspectivas diferentes.
Tomar decisiones basadas en datos y basados en hechos concretos puede ser la mejor estrategia. Por eso, es imprescindible investigar un poco antes de llegar a una conclusión precipitada. Es por ello que quiero compartir contigo diversos aspectos a considerar, mis opiniones personales y referencias de otros profesionales.
Dimensiones
Al analizar lenguajes, y conjunto de lenguajes o ecosistemas ‘stacks’, hay muchos aspectos a considerar. Algunos de estos podrían ser
- Volatilidad de los requisitos: Los proyectos están vivos, las perspectivas cambian... los clientes cambian de opinión... las nuevas tecnologías dan ventaja a otras empresas, y así sucesivamente...
- Hoja de ruta: Una hoja de ruta bien planificada y ejecutada puede ser un impulsor clave del éxito a largo plazo, permitiendo a la organización aprovechar al máximo las tecnologías emergentes y alcanzar tus objetivos. Pudiendo poner en marcha un MVP para evaluar tu proyecto.
- Métricas: el estado de los lenguajes de programación y del ecosistema es importante, por lo que las estadísticas tomadas de StackOverflow y GitHub pueden ayudarte mucho para prever un LTS (Long Term Support).
- Escalabilidad: debemos evaluar si se trata de un proyecto puntual como podría ser una Landing Page para una campaña de Marketing o es un proyecto que se utilizara en el tiempo y por lo tanto deberá ir evolucionando.
- Impacto: no todos los servicios son iguales. Algunos son fundamentales para el funcionamiento de toda la empresa, otros son beneficios.
- Adaptabilidad: ¿qué tan grande será la lógica del desarrollo? Algunos lenguajes de programación son mejores para el mantenimiento que otros. Especialmente debes evaluar la calidad de la documentación.
- Rendimiento: no todos los lenguajes tienen el mismo rendimiento. Muchas veces utilizar un framework que acorta el tiempo de desarrollo, acaba siendo un problema de rendimiento de la aplicación en el futuro.
- Dominio: tu dominio o de tu equipo en un lenguaje de programación limita el conjunto de idiomas para elegir.
- Talento: cuanto más especializado sea el lenguaje de programación, mayor será el coste para atraer el talento o las personas adecuadas a tu equipo. A veces incluso será difícil encontrar alguno.
- Riesgo: ¿cuánto estás dispuesto a poner en juego? ¿Lo terminas a toda costa?
- Dispositivos: ¿el idioma es compatible con Windows? ¿Linux? ¿Mac OS X? ¿Es para teléfono móvil? o ¿es web?
- Integración con otras herramientas: qué tan bien se integra con otros sistema de la organización, como bases de datos, CRM, ERPs, etc. Las APIs són claves en este punto.
- Coste: ¿cuánto dinero es necesario invertir para mantener el desarrollo a largo plazo?
¿De dónde obtener métricas para ayudarte a decidir?
Cualquier decisión debe ser respaldada con hechos. Es por ello que con la ayuda de herramientas online puedes evaluar tus decisiones y ahorrarle mucho tiempo resolviendo dudas.
OSS Insights
Es excelente para obtener información histórica de la calidad e interacción de repositorios. Como:
- Volúmenes de Pull Requests a lo largo del tiempo y sus clasificaciones.
- Tiempo de respuesta a los problemas a lo largo del tiempo.
- Cuestiones abiertas frente a cuestiones cerradas.
RepoTracker
Proporciona varias métricas estáticas del repositorio de GitHub, en particular:
- numero de estrellas
- número de contribuyentes
- tasa diaria de emisión/pr/compromiso
Developer Survey de StackOverFlow
En mayo de 2023, más de 90 000 desarrolladores respondieron a nuestra encuesta anual sobre cómo aprenden y suben de nivel, qué herramientas utilizan y cuáles desean. La más interesante es la sección de tecnología.
Tags de StackOverFlow
Aquí puedes inspeccionar una etiqueta particular en busca de datos.
- número total de publicaciones vs sin respuesta
- etiquetas relacionadas para tecnologías coincidentes
Estos recursos combinados pueden brindarte una comprensión general hacia dónde se dirige el ecosistema. Luego, después de escanear varios candidatos, el siguiente paso es profundizar y leer más material y documentación.
Planificar con antelación y conceptualizar
En la actualidad basamos los desarrollos en métodos ágiles para el desarrollo de software. Te ayuda a adaptarse mejor a lo desconocido. Pero aún así, cuando se trata de tecnologías, todavía es necesario pensar en el futuro.
Elaborar una hoja de ruta para al menos dos años. Luego piensa en los componentes que ayudarán a lograr lo que se necesita:
- Verifica las métricas del framework.
- Lee las publicaciones principales en StackOverflow en busca de etiquetas
- Lee la documentación oficial
- Intenta predecir los puntos débiles
Hay muchas cosas a considerar. ¿Cómo se integra el idioma con la base de datos de su elección? ¿estás como con el lenguaje del ecosistema? ¿Es reemplazable por otra solución? ¿es seguro y cuenta con capacidades criptográficas? Y todo aquello que creas relevante.
No vivimos en un mundo perfecto y, a veces, no se cumplen todos los criterios:
- Efectividad: la herramienta solo hace su trabajo a mitad de camino o cubre sólo un subconjunto de funcionalidades.
- Coherencia: el framework no encaja bien con el código existente y hay que hacer un esfuerzo para integrarlo.
- Eficiencia: es lento o consume demasiada memoria.
- Sostenibilidad: se requiere mucho tiempo para capacitar al equipo, el conocimiento debe actualizarse.
Debes discutirlo con las partes interesadas y acordar las ventajas y desventajas de cada elección. Debes comprender todas las opciones que tienes sobre la mesa y presentarlas al personal no técnico con las posibles variantes.
Prueba de concepto y PMV
Ser práctico siempre supera a los conceptos teóricos. Crear un modelo es la única forma de saber si la tecnología se adapta bien. Cuando tengas un POC (proof of concept), prueba de concepto, en funcionamiento, podrás iniciar el proyecto desde él. Esta es la parte creativa, luego el desarrollo posterior es mucho más predecible.
Recomiendo desarrollar muchas versiones al mismo tiempo, eliminando algunas a lo largo del camino mientras se experimenta con diferentes frameworks. No apostaría todo en un lenguaje o ecosistema, elegiría entre 3 y 4. El período de tiempo depende de ti, pero es mejor no exceder las dos semanas. Cuanto más tardes, más cansado o enganchado estarás a una determinada tecnología. Y el resultado debería ser una estimación fría y calculada.
Desarrollar POC equivale a evaluar la viabilidad de la solución. Este es el momento en el que se decide el presupuesto. También evalúa los riesgos que pueden sabotear el producto a largo plazo.
Una vez que la prueba de concepto se estabiliza, comienza a trabajar el PMV (producto mínimo viable). La diferencia es que este último debe ser un producto listo para ser mostrado a las partes interesadas o clientes. Su objetivo principal es obtener comentarios y hacer correcciones si es necesario. PMV debería tardar como máximo un par de meses.
Recuerda, es sólo un subconjunto básico de funciones. Un error es intentar implementar demasiado. La solución se presenta a los consumidores, por lo que las soluciones de observabilidad deben estar implementadas. A veces será necesario enrutar el tráfico para realizar pruebas A/B.
Favorece la adaptabilidad en entornos dinámicos
Algunas empresas requieren cambios constantes y alinearse con las nuevas tendencias. Suelen ser proyectos en el límite de la investigación y la ingeniería.
El lenguaje ideal debería:
- proporcionar una forma de abstraer las cosas
- ser polivalente con un gran ecosistema de bibliotecas
- facilitar el desarrollo rápido
- tener un buen apoyo de los propietarios del framework
Los nuevos lenguajes representan la mayoría de estas características, pero no los más nuevos que todavía están buscando su sitio.
- JavaScript: Es excelente para el desarrollo web. Es flexible, con buen apoyo de la comunidad, permite un desarrollo realmente rápido.
- Go: bueno para construir sistemas escalables, debido a su simplicidad. También es muy eficaz y está diseñado para la programación de sistemas.
- Kotlin: tiene un ecosistema sólido debido a que se ejecuta en JVM. Es muy versátil y de tipo estático. Es bueno para el desarrollo móvil.
- Python: es simple y fácil de entender. Tiene una amplia colección de bibliotecas y una comunidad sólida.
Herramientas estables para componentes críticos
El ritmo de evolución del software es bastante rápido hoy en día. La supervivencia de una herramienta en particular es cuestión de un par de años y después de este tiempo la consideraría segura en el futuro.
La mayor parte del software tiene una arquitectura en capas con un núcleo en el medio. No cambia mucho durante la vida útil de una aplicación (si es que alguna vez cambia). Así que lo que buscamos no es un desarrollo rápido. Mejor un lenguaje que sea predecible y que se mantenga en el futuro.
Estandariza lo que tienes
Algunas empresas establecen estándares internos para fomentar la comunicación y la eficacia de los equipos. La estandarización puede implicar los mismos lenguajes, procesos y herramientas. Por ejemplo, Netflix utilizó Java y luego pasó a Spring.
La pregunta es ¿cuál es la mejor tecnología para tu proyecto? La respuesta es, como siempre, depende.
El coste es proporcional a la distancia conceptual entre los ecosistemas. Una cosa es reescribir algunos servicios de Java a Kotlin. Y una cosa completamente diferente es reescribir una solución ensambladora nativa para microservicios en Java.
Luego también está el concepto de sinergia: el poder combinado de los equipos es mayor que la suma de ellos. El exceso de comunicación y los problemas de depuración no ayudan a la sinergia. Y esto es lo que pides cuando tienes mucha tecnología en tu solución. Por eso la estandarización es mejor a escala global.
Mi opinión personal es que deberías tener una buena razón para introducir un nuevo lenguaje en tu proyecto. Algunas de estas podrían ser, atraer más fácilmente talento, hace más fácil el trabajo o que la antigua solución se volvió comercial o se ha desatendido.
Conclusión
Cualquier decisión que tomemos está cargado de cierto grado de riesgo, eso es un hecho. Pero no deberíamos abstenernos de ello, deberíamos gestionarlo de forma proactiva.
No hay una mejor tecnología, es por ello que tu perspectiva, conocimiento y negocio te ayudarán a evaluar la mejor solución.
