{"id":35408,"date":"2026-03-09T13:51:17","date_gmt":"2026-03-09T12:51:17","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=35408"},"modified":"2026-03-09T13:51:19","modified_gmt":"2026-03-09T12:51:19","slug":"la-ingenieria-de-lo-posible-mas-alla-del-dogma-de-las-buenas-practicas","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/es\/uncategorized-es\/la-ingenieria-de-lo-posible-mas-alla-del-dogma-de-las-buenas-practicas\/","title":{"rendered":"La Ingenier\u00eda de lo Posible: M\u00e1s all\u00e1 del Dogma de las “Best Practices”"},"content":{"rendered":"\n
Cuando nos enfrentamos a un problema de programaci\u00f3n, a menudo escuchamos frases tranquilizadoras pero limitantes:<\/p>\n\n\n
\"Esto ya ha sido resuelto por [insertar nombre de gur\u00fa aqu\u00ed], solo sigue las mejores pr\u00e1cticas.\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
Por un lado, estas palabras deber\u00edan tranquilizarme: mi problema ya ha sido decodificado y resuelto por mentes iluminadas. Por otro lado, me hacen sentir inadecuado, como si fuera un hereje incapaz de ver la “luz” de la soluci\u00f3n perfecta, repitiendo errores superados desde hace cientos de a\u00f1os de historia inform\u00e1tica.<\/p>\n\n\n\n
Frases as\u00ed nos llevan a creer que la inform\u00e1tica es una ciencia exacta, como las matem\u00e1ticas, donde 2+2 siempre es 4. Sugieren que si el proyecto est\u00e1 en el caos, si la deuda t\u00e9cnica nos asfixia o si el cliente est\u00e1 furioso, la culpa es exclusivamente nuestra: no hemos aplicado correctamente “La Receta”. Pero despu\u00e9s de a\u00f1os de teclados desgastados, empiezo a hacerme una pregunta inc\u00f3moda: \u00bfy si las recetas de los Gur\u00fas fueran una estrella polar, \u00fatil para navegar, pero peligrosa si se confunde con el puerto de destino?<\/p>\n\n\n\n
Para parafrasear al contador Ugo Fantozzi:<\/p>\n\n\n
\"Despu\u00e9s de tres meses de lecturas malditas, Fantozzi vio la verdad y se turb\u00f3 ligeramente, o mejor dicho, se cabre\u00f3 como una bestia. \u00a1Entonces siempre me han tomado el pelo!\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
No se trata de menospreciar a los gigantes de la TI, sino de entender que ellos describen la excelencia en condiciones ideales. Nuestra misi\u00f3n, en cambio, es la ingenier\u00eda de lo posible. Un Senior no es quien sobrevive al barro, sino quien dise\u00f1a la forma de sanear el terreno, un paso a la vez.<\/p>\n\n\n\n
El espejismo del “Greenfield” y la estrategia en el “Brownfield”<\/h2>\n\n\n\n
Los “libros sagrados”, desde Extreme Programming hasta Clean Code, florecen en el “Greenfield”: praderas verdes donde se construye desde cero, con equipos de alto nivel, presupuestos el\u00e1sticos y cultura del fracaso. Kent Beck, Martin Fowler, Dave Farley y Robert C. Martin (Uncle Bob) son mentes brillantes, pero sus teor\u00edas asumen un contexto que en la realidad es m\u00e1s \u00fanico que raro. Memes como<\/p>\n\n\n
\"Tiene que estar listo para ayer\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
no son solo bromas, son los l\u00edmites de nuestro campo de juego. La realidad de la mayor\u00eda de nosotros es el Brownfield: monolitos estratificados desde 1995, bases de datos con campos llamados campo1, campo2, campo3 (con un manual que explica el significado de cada uno) y documentaci\u00f3n “en la cabeza” de ex colegas.<\/p>\n\n\n\n
Recuerdo un proyecto en el que un hilo de sangre me sal\u00eda de los ojos cada vez que ten\u00eda que entender qu\u00e9 estaba pasando en la base de datos. A menudo trabajamos en sistemas que no se pueden tocar porque “nadie sabe qu\u00e9 pasa si borras esa columna”. La seniority aqu\u00ed no es resignaci\u00f3n, es estrategia. Decir “el problema est\u00e1 resuelto” citando un libro es como sugerir el l\u00e1ser a un cirujano bajo bombardeos. El verdadero profesional sabe que el objetivo no es solo salvar al paciente hoy, sino mejorar las condiciones del hospital de campa\u00f1a para que ma\u00f1ana la intervenci\u00f3n sea m\u00e1s sencilla.<\/p>\n\n\n\n
El impuesto sobre la Complejidad<\/h2>\n\n\n\n
El Test Driven Development es una herramienta poderosa, pero si se usa acr\u00edticamente genera arquitecturas retorcidas, saturadas de interfaces in\u00fatiles usadas por una sola clase y mocks fr\u00e1giles que se rompen solo porque ha cambiado el funcionamiento interno del programa, que permanece consistente, pero el mock no.<\/p>\n\n\n\n
El riesgo es un c\u00f3digo “testeable”, pero ilegible. Para los juniors esta pir\u00e1mide de abstracciones es a menudo motivo de orgullo: “\u00a1Guau, qu\u00e9 arquitectura fant\u00e1stica!”. Para un Senior, en cambio, existe la amarga conciencia de que quien escribi\u00f3 ese c\u00f3digo podr\u00eda haber dejado la empresa antes de que sea necesario pasar las noches en producci\u00f3n depurando un bug incomprensible. Es el momento de la fuga: el c\u00f3digo fue escrito para mejorar el CV, no para ser mantenido.<\/p>\n\n\n\n<\/figure>\n\n\n\n
\u00bfY el Clean Code? La obsesi\u00f3n por las funciones de tres l\u00edneas puede convertirse en una pesadilla. He trabajado en proyectos donde para entender un env\u00edo ten\u00edas que abrir 18 archivos diferentes constituidos en un 60% por comentarios heredados como este tomado del c\u00f3digo base del n\u00facleo de Linux:<\/p>\n\n\n
La esperanza aqu\u00ed reside en la calidad como eficiencia: 50 l\u00edneas de c\u00f3digo secuencial son a menudo m\u00e1s mantenibles que un rompecabezas de micro-funciones abstractas dispersas por todas partes, cada una con un nombre tan largo como una frase y un test que simula tres niveles de dependencias. El cliente no paga por la elegancia, paga para que funcione.<\/p>\n\n\n\n
Continuous Delivery vs. Oficina de Compliance<\/h2>\n\n\n\n
Dave Farley nos ense\u00f1a que deber\u00edamos lanzar a producci\u00f3n varias veces al d\u00eda. El despliegue no deber\u00eda ser un evento, sino un “no-evento” libre de estr\u00e9s. Hermoso. Pero luego intente decirle eso a la oficina de cumplimiento de un banco o al responsable de seguridad de una empresa que gestiona datos sensibles.<\/p>\n\n\n
Ah, \u00bfquisieran hacer despliegue cada hora?\nAqu\u00ed est\u00e1 el pase A-38 para completar por cada lanzamiento, firmado por el jefe de departamento, el CISO y el DPO.\nSe necesita un plan de rollback validado y la ventana de despliegue es el martes entre las 2 y las 4 de la madrugada.<\/code><\/span><\/pre>\n\n\n
El Gur\u00fa te dir\u00e1 que es un problema cultural. Pero el desarrollador no tiene el poder de reescribir las leyes bancarias europeas o de convencer al auditor de que “nuestros tests cubren todo”. Esas reglas nacieron de la sangre de desastres reales: alguien hizo un despliegue un viernes por la noche borrando los datos de diez mil clientes. La seniority estrat\u00e9gica acepta estos muros de goma e intenta automatizar lo que es posible, sin ignorar las restricciones de la realidad burocr\u00e1tica.<\/p>\n\n\n\n
Microservicios: Escalabilidad vs Simplicidad<\/h2>\n\n\n\n
“Los monolitos no escalan”. Y as\u00ed dividimos sistemas eficientes en 47 microservicios que se comunican entre s\u00ed con siete protocolos diferentes (o llamadas directas a la base de datos ajena porque no hab\u00eda tiempo para la API). El gr\u00e1fico de dependencias parece el dibujo de mi hijo en la guarder\u00eda cuando “le gustaba hacer c\u00edrculos”.<\/p>\n\n\n\n
La depuraci\u00f3n se convierte en una b\u00fasqueda del tesoro entre logs desincronizados en m\u00faltiples contenedores, donde tail y grep se consideran cosas de pobres. Pero en mi empresa tenemos 100 usuarios concurrentes: CIEN. Un volumen de tr\u00e1fico que incluso un monolito en Visual Basic 6 gestionar\u00eda sin sudar. Hemos creado una complejidad inmensa para resolver un problema que no ten\u00edamos, solo porque “Netflix lo hace as\u00ed”. T\u00fa no eres Netflix; no tienes 10.000 ingenieros. La seniority es saber decir “no” a la complejidad in\u00fatil.<\/p>\n\n\n\n
Agile: de manifiesto a burocracia<\/h2>\n\n\n
\"Individuos e interacciones sobre procesos y herramientas\"<\/span>.<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n<\/figure>\n\n\n\n
Luego te encuentras en daily standups de 45 minutos donde nadie empieza a hablar, y cuando te toca a ti inventas una “supercazzola” (palabrer\u00eda sin sentido) porque te averg\u00fcenza decir que has perdido ocho horas de vida por una codepage de la tabla de la base de datos no alineada. Hemos transformado un manifiesto de libertad en una industria de certificaciones, Scrum Master, SAFe y KPI. La agilidad se transforma en burocracia con un vocabulario diferente. La esperanza es que la esencia del Agile resida en el equipo que se habla de verdad, protegi\u00e9ndose de las “features ad personam” dictadas por gerentes que piden estimaciones basadas en la nada (o en el nombre de la propia feature). La agilidad es una actitud, no un tablero en Jira.<\/p>\n\n\n\n
Gestionar la Deuda: M\u00e1s all\u00e1 del s\u00edndrome del TODO<\/h2>\n\n\n
\"Deja el c\u00f3digo mejor de como lo encontraste\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
Una regla de oro, pero que no debe convertirse en una justificaci\u00f3n para refactorizaciones infinitas que retrasan los plazos. El Senior sabe que a\u00f1adir un “if feo” no es una derrota si se hace con m\u00e9todo. No basta con escribir un TODO que nadie leer\u00e1 nunca.<\/p>\n\n\n\n
Gestionar la deuda significa negociarla: se inserta el parche para respetar el plazo, se abre un ticket de refactorizaci\u00f3n y se acuerda que el “pr\u00e9stamo” t\u00e9cnico debe ser devuelto. Quiz\u00e1s en agosto, cuando tienes tiempo para razonar porque todos est\u00e1n en la playa (y t\u00fa ir\u00e1s en septiembre). Esta es la diferencia entre un Senior y un aficionado: el primero contrae una deuda consciente, el segundo crea un desastre involuntario.<\/p>\n\n\n\n
La Met\u00e1fora del Tavernello: Scope vs Calidad<\/h2>\n\n\n\n
Una vez me dijeron:<\/p>\n\n\n
\"Si tienes 3 euros en el bolsillo compras un Tavernello, no un Barolo.\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
Es una analog\u00eda poderosa. En TI, usar un producto que no cubre correctamente los requisitos puede causar problemas m\u00e1s grandes que los que se tendr\u00edan comprando un producto de gama alta. El verdadero compromiso no debe referirse a la calidad intr\u00ednseca (el c\u00f3digo debe ser correcto, seguro y probado), sino al alcance (qu\u00e9 hacemos). Si tienes poco presupuesto, no cocines un almuerzo de bodas mediocre: prepara una excelente pasta con tomate. Simplifica los requisitos, no el cuidado con el que escribes las l\u00edneas de c\u00f3digo.<\/p>\n\n\n\n
Recuerdo un video donde Luca Mezzalira hablaba de DAZN: para cambiar el a\u00f1o en el pie de p\u00e1gina de los sitios, editan a mano 4 archivos. \u00bfSoluci\u00f3n sucia? Tal vez. Pero en 5 minutos est\u00e1 hecha, riesgo cero e impacto baj\u00edsimo. Si lo hacen los Gur\u00fas de los microservicios, tal vez no sea tan incorrecto. Ese c\u00f3digo “feo” a menudo sobrevive a\u00f1os generando valor, mientras que el c\u00f3digo “bonito” hiper-ingenierizado se reescribe despu\u00e9s de seis meses porque nadie sabe c\u00f3mo tocarlo.<\/p>\n\n\n\n
Los Gur\u00fas venden libros, nosotros vendemos soluciones<\/h2>\n\n\n\n
Los Gur\u00fas son chefs con estrellas que compran ingredientes de primera calidad. Nosotros somos los cocineros que deben alimentar a 200 personas en una hora. Si intentas replicar la receta del Tiramis\u00fa de Iginio Massari sin tener tiempo para los bizcochos caseros, terminar\u00e1s con las personas y\u00e9ndose a casa molestas por la espera. Usa las galletas del supermercado y conc\u00e9ntrate en una crema decente.<\/p>\n\n\n\n
Debemos crear soluciones basadas en la realidad. Los Gur\u00fas se\u00f1alan la cima, pero somos nosotros los que debemos trazar el sendero entre las zarzas. La excelencia es proporcionar la m\u00e1xima calidad posible dentro de las restricciones dadas, no quejarse de las restricciones mismas.<\/p>\n\n\n\n<\/figure>\n\n\n\n
\u00bfPero entonces somos viejos o senior?<\/h2>\n\n\n\n
La diferencia es que el viejo ha dejado de aprender, el senior ha dejado de ser un fan\u00e1tico. El senior ha estudiado las reglas tan bien que sabe exactamente cu\u00e1ndo romperlas para salvar el proyecto, transformando esa excepci\u00f3n en un acto consciente de ingenier\u00eda.<\/p>\n\n\n\n
Ha aprendido que “depende” es la respuesta m\u00e1s honesta. Que el c\u00f3digo perfecto es enemigo del c\u00f3digo que funciona. Que entregar el 90% a tiempo es mejor que el 100% con retraso. Y si esto significa pasar por alguien que “vive en la zona de confort” a los ojos de quien hace vibe coding con el \u00faltimo framework publicitado en X: me har\u00e9 a la idea.<\/p>\n\n\n\n
Nos vemos en la trinchera. Chapoteamos en el barro, mantenemos en pie monolitos y construimos puentes. Porque al final, la culpa no es de los Gur\u00fas que nos hicieron creer en la perfecci\u00f3n, sino nuestra si dejamos de buscar la excelencia posible para perseguir la imaginaria.<\/p>\n","protected":false},"excerpt":{"rendered":"
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-2-nanobanana.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-3-nanobanana.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-es-infografica.png\")
<\/figure>\n\n\n\n