Python, JavaScript, Java, PHP: qué te está diciendo tu proveedor cuando los nombra
No necesitas saber programar, pero sí qué implica cada lenguaje en coste, en velocidad de cambio y en encontrar a quien lo mantenga dentro de tres años.
En una reunión de presupuesto, alguien de tu proveedor dice «lo vamos a montar en Python» o «esto lo llevamos en PHP» y tú asientes porque interrumpir para preguntar «¿eso es bueno o malo?» parece delatar que no tienes ni idea. La reunión sigue. Nadie vuelve a mencionar el lenguaje. Y sin embargo, esa frase suelta al pasar es una de las pocas decisiones de esa reunión que te va a acompañar durante años.
No hace falta saber programar para entenderla. Hace falta saber qué preguntar.
#La idea que hay que romper primero
No existen lenguajes mejores y lenguajes peores, a pesar de lo que digan los foros donde la gente discute esto con la pasión de un derbi de fútbol. Existen lenguajes más adecuados para un tipo de problema, y equipos que dominan uno mejor que otro. Un martillo no es superior a un destornillador: depende de si hay un clavo o un tornillo delante.
Lo que sí varía muchísimo entre lenguajes, y es lo que te afecta a ti como quien paga, cabe en tres cosas muy concretas: cuánta gente en el mercado sabe usarlo bien, cuánto cuesta esa gente, y qué pasa el día que tu proveedor actual desaparece y necesitas que otro continúe donde él lo dejó. «Cuál es más elegante» no entra en la lista.
#Qué implica cada elección, en la práctica
| Lenguaje | Para qué se usa habitualmente | Facilidad de encontrar quien lo domine | Señal de alarma |
|---|---|---|---|
| JavaScript | Todo lo que se ve en un navegador: la web con la que interactúa tu cliente | Muy alta. Es el lenguaje más extendido del mundo | Que se use para todo, incluidas partes donde otro lenguaje encajaría mejor solo porque «el equipo ya lo sabe» |
| Python | Análisis de datos, automatizaciones, herramientas internas, inteligencia artificial | Alta. Mercado muy amplio y creciendo | Ninguna especialmente propia; es de los lenguajes más seguros para contratar hoy |
| Java | Sistemas grandes de empresa, banca, seguros, aplicaciones que llevan diez años funcionando sin parar | Alta entre perfiles senior, más difícil entre perfiles jóvenes | Que un sistema Java lleve una década sin que nadie lo toque «porque funciona»: cuando haya que tocarlo, cuesta encontrar quien quiera hacerlo |
| PHP | Gestores de contenido, tiendas online, webs de gestión clásicas | Alta, aunque con reputación injustamente peor de la que merece | Código muy antiguo, de hace más de diez años, escrito antes de que el propio lenguaje adoptara buenas prácticas actuales |
| Ruby | Aplicaciones de gestión a medida, startups que crecieron rápido hace una década | Media-baja. Cada vez menos gente nueva lo aprende | Que sea la única razón por la que sigues dependiendo de una sola persona |
La tabla no es un ranking. Es una foto de mercado. Un sistema en Java bien escrito puede llevar quince años funcionando sin fallar una vez; uno en JavaScript recién montado puede estar lleno de decisiones improvisadas. El lenguaje es el material, no la obra.
Fíjate en que ninguna columna de esa tabla dice «rápido» o «lento», ni «moderno» o «viejo». Esas dos etiquetas son las que más circulan en las conversaciones informales sobre tecnología, y las dos son casi irrelevantes para tu negocio. Un lenguaje «antiguo» con una comunidad enorme detrás es una apuesta más segura que uno «moderno» que solo dominan cien personas en el mundo. La velocidad de ejecución, salvo en negocios muy concretos con volúmenes altísimos, casi nunca es el factor que decide si un proyecto sale bien o mal: lo decide la disponibilidad de gente que lo sepa mantener el día de mañana.
#Lo que sí debe preocuparte de verdad
Da igual el lenguaje que elija tu proveedor. Lo que importa es una cosa: que ese lenguaje tenga una comunidad activa detrás y siga recibiendo actualizaciones de seguridad.
Piénsalo como el mantenimiento de una instalación eléctrica. No importa tanto la marca del cableado como si el fabricante sigue existiendo y sigue sacando piezas de repuesto. Un lenguaje de programación que ya nadie mantiene —porque su comunidad se ha ido a otra cosa, porque la empresa que lo creó lo abandonó— deja de recibir los parches que tapan agujeros de seguridad recién descubiertos. Los agujeros se siguen descubriendo. Los parches, no.
Eso convierte un sistema construido sobre un lenguaje sin mantenimiento en un problema de seguridad con fecha de caducidad conocida por todos menos por ti. No hablamos de una posibilidad remota, sino de una cuestión de tiempo: cuanto más tarde, más caro y más urgente será el día que toque moverse.
#La pregunta trampa: cuando te proponen algo muy nuevo o muy raro
Hay un momento en el que conviene afinar el oído: cuando alguien te propone construir algo con una tecnología muy reciente —lanzada hace meses, todavía sin recorrido— o muy de nicho, que casi nadie usa fuera de un círculo pequeño de entusiastas.
No es que esa tecnología sea mala. A veces es genuinamente mejor para el problema que tienes. Pero antes de aceptar, hay dos preguntas que tienes todo el derecho a hacer, y que cualquier proveedor serio debería poder responder sin incomodarse:
- ¿Quién más la usa en producción, no en un proyecto de prueba? Si la respuesta es «pocos, pero es el futuro», estás pagando para formar parte de un experimento.
- ¿A quién llamo si tú te vas y necesito seguir? Si la respuesta tarda en llegar, es porque la respuesta es «a nadie», y eso significa que dependes de una sola persona para siempre.
Imagina una sala de conciertos que le pide a su proveedor un sistema de control de aforo en tiempo real. Un proveedor propone construirlo con una herramienta que acaba de salir, muy prometedora, que él domina porque la ha probado en sus ratos libres. Otro propone una tecnología con quince años de recorrido, aburrida pero con miles de empresas usándola a diario. La primera opción puede que resuelva el problema igual de bien. Pero si ese proveedor desaparece dentro de dos años, la sala de conciertos se queda con un sistema que casi nadie en el mercado sabe tocar, mientras que la segunda opción tiene cientos de candidatos disponibles para continuarlo.
Ninguna de las dos elecciones es automáticamente incorrecta. Lo incorrecto es no haberte hecho la pregunta antes de firmar. Y hay un matiz importante: esto no significa que debas rechazar siempre lo nuevo. Significa que lo nuevo debe venir acompañado de una razón de negocio explícita —resuelve algo que la opción probada no resuelve— y no solo del entusiasmo de quien lo propone por estrenar herramienta.
#Cuatro preguntas para la próxima reunión de presupuesto
No necesitas fingir que sabes programar. Necesitas hacer las preguntas que un comprador informado hace siempre, en cualquier sector:
- ¿Cuánta gente en el mercado, hoy, sabe trabajar con esto? No «cuánta gente lo usa en el mundo», sino cuánta gente contratable cerca de ti lo domina.
- ¿Qué pasa si tu empresa cierra o tú dejas el proyecto? Quien tiene una respuesta clara y tranquila ya se lo ha planteado antes que tú. Quien se pone a la defensiva, no.
- ¿Sigue recibiendo actualizaciones de seguridad esta tecnología, y con qué frecuencia? Es una pregunta técnica con una respuesta que cualquiera puede verificar sin saber programar: basta con buscar la fecha de la última actualización pública.
- ¿Por qué esta y no la opción más habitual del sector? La respuesta no tiene por qué convencerte técnicamente. Lo que importa es que exista, y que no sea «porque es lo que yo sé hacer».
La próxima vez que alguien nombre un lenguaje de programación en una reunión, no necesitas saber qué es. Necesitas saber que acaba de tomar, en tu nombre, una decisión que vas a pagar durante años.