Hay cosas que deberían descansar en paz, pero siguen apareciendo en todos los proyectos de software. Da igual cuántos años lleves programando, cuántas migraciones hayas sobrevivido o cuántas veces hayas prometido que esta vez sí ibas a dejarlo todo bien documentado. Siempre hay algo que vuelve para perseguirte.
En Halloween hablamos de fantasmas, zombis y criaturas que aparecen cuando menos te lo esperas. Pero cualquier developer sabe que hay cosas bastante más aterradoras que un pasillo oscuro: un deploy el viernes por la tarde, un ticket urgente que lleva cinco días abierto o una función que nadie entiende, pero que, por algún motivo, mantiene toda la aplicación en pie.
Bienvenido al cementerio del código. No hace falta traer flores. Mejor trae un café, un entorno de pruebas y muchas ganas de no tocar nada.
1. El deploy del viernes
Viernes, 17:42. Todo parece estar en orden y el equipo ya está pensando en el fin de semana. Entonces alguien pronuncia las palabras malditas: «Es un cambio pequeño, lo subimos y listo».
¿Qué podría salir mal?
A veces, todo. El servicio deja de responder, los logs empiezan a echar humo y ese pequeño cambio se convierte en una sesión de debugging que nadie había incluido en su calendario.
El deploy del viernes no entiende de planes, horarios ni conciliación. Y aunque sabemos que hay buenas prácticas para evitarlo, siempre existe la posibilidad de que alguien decida tentar a la suerte.
Estado: descansa en paz. O eso esperamos.
2. La documentación que viajó al pasado
La documentación existe. Está en el repositorio, tiene su carpeta y hasta cuenta con un README bastante prometedor.
El problema es que la última actualización fue hace tres años.
Desde entonces, la arquitectura ha cambiado, hay dos servicios nuevos y aquel compañero que conocía todos los secretos del sistema ya no trabaja en la empresa. Pero el documento sigue ahí, asegurando con total confianza que basta con ejecutar tres comandos para levantar el proyecto.
Y tú los ejecutas. Por supuesto que los ejecutas.
Después de varios errores, descubres que faltan variables de entorno, que una dependencia ya no existe y que el tercer comando pertenece a una versión de la aplicación que nadie recuerda.
Estado: desaparecida en combate. Última vez vista hace tres años.
3. El proyecto de tres meses que se volvió inmortal
Todo empezó con una estimación razonable. Tres meses de desarrollo, unas cuantas funcionalidades y una fecha de entrega que parecía perfectamente asumible.
Tres meses después, el proyecto estaba casi terminado.
Seis meses después, seguía casi terminado.
Dos años después, alguien continúa diciendo que ya solo quedan unos pequeños ajustes.
Mientras tanto, han cambiado los requisitos, se han incorporado nuevas funcionalidades y el proyecto ha sobrevivido a varias reorganizaciones del equipo. Lo que iba a ser una solución temporal ya tiene más temporadas que tu serie favorita.
Lo peor es que nadie se atreve a preguntar cuándo acabará. No vaya a ser que la respuesta implique otra planificación, otra reunión y una nueva estimación de tres meses.
Estado: 2023–∞. «Ya casi está».
4. El código que funciona y nadie se atreve a tocar
Hay partes de un proyecto que todos conocemos. Esas funciones que parecen escritas en otro idioma, con condiciones anidadas, nombres misteriosos y una lógica que desafía cualquier explicación racional.
Nadie sabe exactamente por qué funcionan. Nadie recuerda quién las escribió. Y, sin embargo, cada vez que alguien intenta refactorizarlas, aparece un bug que afecta a una funcionalidad completamente distinta.
Así que el equipo llega a un acuerdo tácito: si funciona, no se toca.
La solución no es precisamente un ejemplo de mantenibilidad, pero hay algo que impone respeto en ese fragmento de código. Ha sobrevivido a cambios de framework, actualizaciones de dependencias y a tres personas que juraron que lo reescribirían.
Estado: no molestar. La criatura está dormida.
5. El ticket urgente que nunca muere
Llega el lunes y aparece un ticket marcado como urgente. Hay que revisarlo cuanto antes.
El martes sigue siendo urgente. El miércoles alguien pregunta por su estado. El jueves se mueve a otra columna del tablero y el viernes continúa ahí, tan urgente como el primer día.
Mientras tanto, el equipo ha resuelto otros problemas, ha atendido nuevas peticiones y ha sobrevivido a un par de reuniones que podrían haber sido un mensaje. Pero ese ticket sigue esperando su momento.
Lo curioso es que, cuanto más tiempo pasa, más difícil resulta recordar por qué era tan urgente en primer lugar.
Estado: oficialmente abierto. Extraoficialmente, parte del mobiliario.
Un cementerio con sitio para más víctimas
Si algo nos enseña trabajar en tecnología es que los proyectos están llenos de historias que se repiten. Cambian los lenguajes, las herramientas y las metodologías, pero algunos clásicos siguen resistiendo el paso del tiempo.
Y seguro que, mientras leías esta lista, te ha venido a la cabeza algún otro sospechoso: el bug que solo aparece en producción, el servidor que nadie sabe quién mantiene o la tarea que siempre se deja para el siguiente sprint.
Ahora te toca a ti.
¿Qué añadirías al cementerio del código? Cuéntanos esa historia que todavía recuerdas, ese error que te quitó el sueño o esa parte del proyecto que nadie se atreve a tocar. Prometemos no modificar nada que funcione por motivos que nadie comprende.
🎃 Este Halloween, llévate un regalo de Codemotion
No todo van a ser sustos. Si estás pensando en venir a Codemotion Madrid 2027, tenemos un pequeño regalo para ti: ¡una camiseta de Codemotion gratis!
Solo tienes que seleccionar la entrada Conference Pass al comprar tu entrada y utilizar el código promocional HALLOWEEN . Así, te llevarás una camiseta de Codemotion con tu entrada.
La próxima edición se celebrará los días 12 y 13 de mayo de 2027 en La Nave, Madrid. Dos días para compartir conocimiento, descubrir nuevas ideas y encontrarte con otros profesionales de la comunidad tecnológica.
La promoción estará disponible hasta el 2 de noviembre
¡Feliz Halloween, developers! Y recuerda: que el único susto sea el de producción. 👻
