Una dueña de negocio — la voy a llamar Patricia, no es su nombre real — publicó un aviso de trabajo para un programador que mantuviera un sistema en VB.NET y WebForms que manejaba la operación central de su empresa. Esperaba el goteo habitual de postulaciones en unos días. Tres semanas después, tenía seis postulantes en total, y solo uno había trabajado con WebForms en los últimos cinco años. Los otros cinco eran o recién graduados que nunca habían oído hablar de eso, o programadores senior que pedían una tarifa casi el doble de lo que ella tenía presupuestado, porque sabían exactamente cuán pocas otras empresas podían hacerles esta oferta.
Patricia no había hecho nada mal. Su sistema no estaba mal construido, su empresa no era un mal lugar para trabajar, y su aviso no estaba mal escrito. Simplemente se topó con un problema de contratación que no tiene nada que ver con qué tan bien se construyó un sistema, y todo que ver con dónde eligen los programadores pasar su carrera.
Por qué el grupo de postulantes se achica
Esto no es una escasez repentina — es un drenaje lento que lleva más de una década en marcha. Las universidades y los bootcamps enseñan ASP.NET Core, no Web Forms. La documentación oficial de Microsoft, los tutoriales de YouTube, los proyectos de ejemplo en GitHub, las respuestas de Stack Overflow escritas en los últimos cinco años — casi todo asume .NET moderno. Un programador que aprende el ecosistema hoy casi no tiene motivo para tocar VB.NET o Web Forms, salvo que un trabajo específico lo requiera.
Y los programadores que eligen dónde trabajar lo tienen en cuenta activamente. Alguien más joven que está mirando dos ofertas parecidas — una trabajando sobre una base de código moderna en .NET, otra manteniendo un sistema en Web Forms — a menudo va a elegir la moderna incluso con un salario similar, porque está pensando en qué le aporta esa experiencia para su próximo trabajo, no solo para este. Eso no es falta de lealtad a su empresa. Es una decisión de carrera racional, y significa que el grupo de postulantes para roles legacy se inclina hacia gente cerca del final de su carrera, en lugar de gente que está construyendo una.
El riesgo se acumula a medida que sus expertos se retiran
Acá está la parte que convierte esto en algo más que una incomodidad: los programadores que de verdad conocen bien estos sistemas, en promedio, están envejeciendo, y algunos de ellos son la única persona en su empresa — o a veces la única persona que alguna vez encontraste — que entiende completamente cómo funciona un módulo determinado. Vi empresas donde una persona específica era, en la práctica, un punto único de fallo para todo un sistema crítico, no porque alguien lo planeó así, sino porque nadie la reemplazó antes de que hiciera falta reemplazarla.
Cuando esa persona se jubila, acepta otro trabajo, o simplemente no está disponible por unas semanas, el costo de ese vacío ya no es el que habría sido cinco años antes. Es más alto, porque el grupo del que estás contratando es más chico de lo que era, y se achica un poco más cada año que esperás. Este es un riesgo que se acumula, no uno fijo — el mismo sistema cuesta más de dotar de personal este año de lo que costó el año pasado, y va a costar más todavía el año que viene, independientemente de lo que le pase al código en sí.
Este es un argumento de negocio, no uno técnico
Vale la pena separar esto del argumento puramente técnico para modernizar. Un sistema puede ser técnicamente estable — sin errores, sin caídas, cumpliendo bien su función — y seguir siendo un riesgo real de negocio solo por quién está disponible para mantenerlo funcionando. Trabajé con empresas donde el código en sí no era el problema en absoluto; el problema era que reemplazar a la única persona que lo entendía iba a tomar meses, a un costo mucho más alto que el que habían previsto pagar cuando el sistema se construyó por primera vez.
Esto importa porque cambia la conversación. La pregunta no es solo "¿este sistema todavía funciona?" Es "si la persona que lo mantiene se fuera mañana, ¿cuánto tardaría en reemplazarla, y cuánto costaría eso?" Para muchos sistemas legacy en VB.NET y Web Forms, la respuesta honesta a esa segunda pregunta viene empeorando cada año, en silencio, mientras la primera respuesta seguía siendo "sí, todavía funciona bien".
Hacia dónde apunta esto en realidad
Nada de esto significa desarmar de un día para el otro un sistema que funciona. Significa reconocer que el propio grupo de contratación es un costo que viene subiendo de fondo, y tratarlo como una pieza más de información para decidir qué hacer con el sistema — junto a las preguntas técnicas, no en lugar de ellas.
Un paso hacia .NET moderno y C# no solo abre opciones técnicas; también vuelve a abrir el grupo de postulantes. El grupo de programadores que conoce ASP.NET Core y C# es enorme comparado con el grupo, cada vez más chico, que todavía conoce bien Web Forms y VB.NET, y esa brecha se sigue ensanchando en la misma dirección cada año. Contratar se vuelve más fácil, la capacitación es más rápida, y dejás de depender de un grupo chico y cada vez más envejecido de especialistas para un sistema que su negocio realmente necesita mantener funcionando.
Patricia terminó extendiendo su oferta, pagando por encima de lo presupuestado, y teniendo la suerte de conseguir una candidata dispuesta a quedarse unos años más. Es una solución viable a corto plazo. No es un plan a largo plazo, y ella lo sabía. El grupo de contratación del que sacó esta vez va a ser más chico todavía la próxima vez que necesite recurrir a él, y el costo de esperar no baja mientras tanto.