Mes: noviembre 2025

Nota: Modificado para añadir porque el negocio mencionado no es sustentable ni en consignación ni en venta.

Una persona de mi pasado, mi padre específicamente, decía que hay cosas que caen por su propio peso, y que hay trabajos para CLark Kent y acciones para Supermán.

No diré que mi padre era Supermán pero si le vi hacer cosas de fuerza increíbles. Tanto en el gimnasio como en la vida real.

Aunque murió hace muchos años, a veces me acuerdo de manera aparentemente aleatoria de algunos asuntos. Como eso de lo que ciertas cosas caen por su propio peso.

Ayer tuve una discusión evitable, y no de mi parte iniciada, sobre el asunto de una marcha política de oposición, «generación Z» y su seudo lider. EL PAN acepta que es real el contrato de 2.1 millones de pesos por manejar durante un año cosas de marketing para CDMX con una persona física de 25 años, supuesto estudiante de licenciatura de derecho UNAM recién egresado. Ya chequé y no hay cédula profesional. Es absolutamente ilógico por donde se vea. Que sea abogado en marketing, que se le pague esa cantidad, que se le asigne a una persona física. Dejo de ejercicio para el lector las posibles explicaciones.

Si, cae por su propio peso por absurdo.

Por la experiencia hay cosas que conozco muy bien  podríamos llamarlos .. algoritmos propietarios ? o como se le quiera llamar. Uno de ellos es el proceso de lo que a veces se le llama analista de compensaciones de recursos humanos, incluyendo análisis de puestos. Conozco dos metodologías: Una que desarrollé allá por 1999-2000 en la época del sistema de jueces para uniliver, y una mas moderna que se usa actualmente en gobierno. Un contacto en ese tema de análisis de puestos,  me pidió este año que hiciera unos ajustes, para una empresa que  está en Tlalpan. Los hice. Me pidieron una factura pero no la pagaron con un pretexto. Estaba estipulado que yo no entrego el código hasta 95% del pago del contrato.  En este caso me pidieron hacer un trámite medianamente innecesario Abril ? No me acuerdo. EL caso es que tuve que gastar 8 mil pesos y un extra de 4 mil mas que terminó el asunto. E incluso con ese requisito, le dieron baje, corrieron o lo que sea a la de recursos humanos que si funcionaba y a su jefe, pero también a mi contacto y sin pagarle.

Unos meses después, me llaman. Voy a entrevista con ellos para retomar el proyecto. AL entrar a su bodega de inventarios que estaba de paso a la oficina de los NUEVOS, me sorprendo. Varias banderas rojas. Sin ser ese el ramo imagínate que ves en tlalpan unos 40-80 refrigeradores de dos puertas de los que hacen hielo, del año pasado, y que valen unos 80 mil a 100 mil. Pero ellos no manufacturan refrigeradores. Eso no se vende. No hay mercado. No hay rotación de inventarios. Necesita técnicos especializados. Algo esta muy raro.

Ahora que recuerdo, ellos me dijeron en esa entrevista con los nuevos que tenían cartas invitaciones del imss en las cinco razones sociales. El hecho de que me hayan revelado la existencia de las cartas invitación y aun así rechazaran la solución que exigía transparencia (la lista de puestos del IMSS), prueba que no les importaba solucionar el problema. El problema no eran mis tres soluciones propuestas sino el miedo a la transparencia y la auditoría que mi metodología (cuadrada contra la realidad del IMSS) representaba.

Necesitan también algunas ventajas. No creo que sea compra de liquidación. Quien compra tanto de ese modelo y del mismo color ? simplificación de inventarios de repuesto si. Pero que ? van al sitio ? Todo el background de los mecánicos de ese tipo de cosas es complicado. Certificaciones. Algo esta muy mal.

Les recuerdo que esto es un metáfora. No son refrigeradores pero la idea se mantiene. Tienen millones en activos inútiles, pero no pagan una pequeña deuda. Se necesita espacio, tener el dinero parado y de un producto que crea muchas responsabilidades legales no tiene el mas mínimo sentido.  No compraron a distribuidor. No necesita una ubicación comercial prime; necesita bodegas seguras para almacenar el activo que justifica la inversión en los libros contables. Que todos sean del mismo modelo y color, es igual. Tiene ventajas y desventajas. Pero las ventajas son para mí la bandera roja.  No las desventajas.

Pero NO me ofrecen NADA. Me ponen tres pretextos para el no pagarme la factura, que a estas fechas ya está cancelada. Les ofrezco tres o cuatro alternativas, incluyendo hacerles una nueva factura que es lo obvio. Ellos y yo sabemos que el requisito que me hizo gastar 12 mil pesos es idiota, irrelevante e ilegal.

Les propongo tres alternativas. Primero tienen que tener la lista de los puestos como están en el IMSS. Sin eso no se puede hacer nada. Pero mis tres alternativas son ignoradas. La factura es pequeña. Solo son 35 mil pesos. (menos de 2000 USD) Pagarla les daría el código fuente del sistema. La metodología necesita aplicarse. Tener el código pero no saber hacer ajustes de calibración, lo hace inutil. Y eso es experiencia de mas de diez años.

Salgo y veo los refrigeradores. Todo son del mismo modelo y color. Que nadie compraría. ¿?

Meses después, hoy mismo en noviembre de 2025, el absurdo se hizo aún más evidente. Recibo un aviso en LinkedIn: la misma empresa estaba buscando desarrolladores, ofreciendo un sueldo de $25,000 MXN. Para el stack de tecnologías que solicitan—que en el mercado se cotiza en $40,000 MXN o más—es un salario bajo.

Lo que piden no es para un sitio web, puede ser pero es muy ineficiente. Para lo que sirve esa tecnología es para dashboards vistosos y reportes manipulables. La base de datos lo mismo. No necesita licencias pero si permite procedimientos almacenados que ocultan lógica del negocio. Eligieron algo que está entre dos mundos o stacks pero sin ventajas para una operación real. Y yo que conozco su giro si el producto fuera real o tuvieran movimiento ese conjunto de habilidades (stack) no sirve para nóminas, para facturación electrónica ni para un ERP que, de todos modos, no necesitan. Ese conjunto de herramientas solo es razonable para control de inventarios y mantenimiento de activos. Pero incluso para eso, no es el stack ideal, lo que lo hace doblemente raro.

Es decir, la empresa que tiene millones en activos inútiles parados en CINCO bodegas con muy baja rotación, y que no quiso decirme lo de los puestos ante el IMSS, prefiere pagar un sueldo continuo y subvaluado a un desarrollador interno para construir un sistema de control de inventarios de la nada, en lugar de pagar una pequeña factura de $35,000 pesos por una metodología probada que resolvería su problema REAL de raíz.

No comenté que recibí dos correos hace meses pidiéndome la tabla de calibración en base a los factores y su ponderación, que era equivalente a pedirme el know how. Yo solo les pasé los Números BRUTOS de a A a G de un único puesto de prueba con otro más.

Me hicieron gastar 12 mil pesos de balde.

Ellos necesitan arreglar el problema de manera definitiva a las cartas invitación del IMSS: Pero el stack no concuerda.

Hay algo absurdo.

No quisieron la solución probada porque les exigía ver la lista de puestos ante el IMSS. No quisieron mi know-how porque les daba la herramienta de calibración, y la calibración requiere datos reales. Prefieren hacer algo secundario que el movimiento de su operación no sostiene: la rotación de producto es baja pero de riesgos altos. SAE bien configurado resuelve la rotación y consignación en su caso…. pero no los seguros y cartas porte y control de documentos/contratos. Un script PHP por alguien como yo para la rotación de inventarios incluso a consignación es mucho mas barato y simple. Los números de series, aduanas, garantías. El stack que dicen no es aplicable. … react ? Useeffect ? aduanas ? Literalmente es un helado de pollo rostizado. Teóricamente posible. Piden algo de uso interno con react ?

Prefirieron pagar un sueldo continuo y subvaluado a un desarrollador para construir un sistema, opaco y a la medida de la simulación. El objetivo no era la eficiencia, sino otra cosa.

Uno de los problemas de haber trabajado tanto tiempo en entornos donde pueden haber faltas de probidad, es que soy necesariamente cauteloso, para detectar cosas e implementar procesos que eviten que te pongan una trampa o a alguien mas.

La famosa tarea de licenciatura que tenia que hacer hoy era a mano, lo que se dificulta cuando ya casi no hacen hojas de trabajo tabulares. Esto eran unas 16 columnas para calcular unos recargos de todos los meses de 2023  y que en excel hubiera hecho en unos 15 minutos.

Pero lo mas tardado era pensar como resolver un problema de control interno. la respuesta obvia era usar datos de Noviembre, mes actual, pero nos pedían en base a julio.  Eso no se hace. Puede ser un «cuatro» (trampa de mala fe) o error humano. Lo mas simple en un caso real era entregar los dos y explicar porque se debe usar el de noviembre. Y me tarde mas en redactar un párrafo para expresar el problema de control interno que estaba atrás y porqué usar noviembre, a pesar de la descripción que lo que me tardé en el ejercicio.

En medio de todo esto me buscan por whatsapp la dama margarita y la dama de nombre de piedra preciosa. Una desanimada y la otra de buen humor como siempre.

Unos minutos después me pregunta algo el director de mi ingreso principal. Tiene un problema que ya he resuelto en otras ocasiones, pero solamente sistemas como el mío lo pueden hacer.  Literalmente es confidencial, un ajuste rápido y transparente, pero para mí. Lo tardado son las pruebas del anexo20. En todas las razones sociales. Son razones como esa las que me hacen cobrar iguala en sistemas de ERP. Así que aunque no es demasiado trabajo, al mismo tiempo si lo es. Me esperan unos días  moviditos. Y descubrí que mi webcam no funciona con windows 11 aso que deberé usar laptop para un meet con un prospecto de cliente el viernes.

Nota: Una persona que me lee y estudia contabilidad, me pidió que pusiera el comentario que hice sobre la tarea.

Aqui va:

Este es un problema que lleva control interno de por medio y por desconfiado incluso pensaría en descuido o un cuatro. de manera formal…  Hay un interesante ejercicio aquí por control interno. Lo correcto es hacer el cálculo por dos factores y presentar ambos al dueño, porque hay un descontrol.

Puede justificarse que debe usarse el INPC de junio (140.405) en lugar del de octubre (141.708), usando regla de tres o recalculando los dos factores. Pero este es un trabajo a mano, así que por eso no presento los dos. Por alguna razón estamos haciendo cálculos de tres meses (no de julio), así que el recargo de diferencia debe ser de unos $1,500 entre ambos valores.

Lo sensato es evitarnos problemas y hacer el cálculo con 141.708 y revisar por qué lo estamos viendo hasta hoy. Puede ser descuido o falta de liquidez. También habría que confirmar que realmente no se haya pagado. Vamos a partir del supuesto de que efectivamente no se ha pagado y que solo presento un cálculo a mano, aunque en una empresa como esta presentaría los dos y haría el cálculo sobre noviembre por lo siguiente: Los recargos fueron recalculados con corte a noviembre de 2025, conforme al aviso recibido.

La actualización por INPC permanece con base en octubre de 2025. Estamos hablando de una tarea que debe sostenerse en auditoría. Si bien es cierto que la revisión dice que se hizo en julio, lo cierto es que hoy no se ha pagado en noviembre de 2025. Por lo mismo, lo normal sería revisar por qué nos están avisando hasta hoy y hacer un cálculo realista, que evita cualquier MANIPULACION EXTERNA y evita a la vez depender de documentos que nos pasaron. Como no tengo documento de cantidades del SAT, y sé que no se ha pagado, lo que haría sería usar los datos de octubre de 2025 porque son los públicos y definitivos, y es lo que tenemos que pagar. En el caso de ser algo real, mi informe habría sido: “La cantidad en junio era tal; cierto, no hemos pagado; así que por el retraso de pagar en noviembre y no en julio, la diferencia fue de tantos pesos.” Pero usar los datos de noviembre de 2025 y el factor publicado es lo único defendible ante auditoría, porque es lo que tenemos que pagar hoy.

En una de mis cuentas secundarias de correo, redirección, se esta recibiendo spam de una cuenta argentina, que al vez esta relacionada con un servicio de auto hosteo  (personas que usan su pc como servidores) y que su vez viene de sytes.net, un redirector de direcciones de casa a direcciones de dominios por decirle de algun modo, usado por spammers. Problema es que no se puede bloquear por IP, pero si por dominio, lo que hice hoy.

Al levantar una queja porque es uno a la semana, me encuentro esto al llenar el formulario. Se entiende que usan tecnología de hace 20 años.

Un script de .asp de datamarkets.com.ar que redirige a gracias.asp y muestra todo en texto plano. Desesperación….

y estupidez.

 

Es sábado de puente a finales de noviembre. Aunque ya acabé mi trabajo del día, de soporte a mi cliente principal como DevOps y sacando sus respaldos de la operación, me quedaré en casa sin salir. No por los perros, que salir sin ellos más de dos días no es buena idea, tampoco por cuestiones de dinero.

Normalmente me iría con familia a la feria de noviembre de Tlaxcala, se come bien y sabiendo cómo ir no es caro. Solo que se dan dos características no relacionadas. La primera es que el cliente de los monolitos puso pretexto para pago de enero a mayo y no me pagaron esos meses, porque condicionaba el pago a trabajar gratis hasta diciembre y cometer un delito. La segunda es algo urgente, no importante, que tiene que ver con cuestiones de tiempo.

He comentado que soy de los que leo noticias por trabajo para enterarme cosas del SAT o incluso el Diario Oficial. Pero soy de los que lee la etiqueta del champú. Así que leo mucho y así, por mi profesión doble de desarrollador DevOps desde hace 33 años, y mi formación como contador público, pues me hacen ver detalles donde otros no los ven. Corazonadas que otros no pueden explicar pero que me hacen ver posibilidades, detectar posibles fraudes, y me he enfocado en continuidad de negocio.

Hace unos 12 años, un sábado como a las dos de la tarde leí una nota de cambio que iba a suceder en World of Warcraft, que jugábamos mi esposa y yo. Así que le dije: va a haber una devaluación y van a cambiar la moneda de las misiones. Hay que apurarnos para comprar lo que querías. Nos pusimos ese fin de semana a hacer más cosas en el juego y terminamos como con tres puntos sobrantes cada uno después del objetivo, que era conseguir heirlooms y otras cosas. Y así fue. El lunes metieron un cambio casi sin avisar, que bajó el valor de lo que teníamos a un cuarto, y nos hubiéramos tardado meses en conseguir eso. Así que eso era urgente, pero no importante.

Otro ejemplo fue en 2017. Iba a venir el cambio de gobierno de AMLO, yo soy apolítico pero me encontré de repente de manera definitiva con dos hijos de 14 y 9 que me pasó su mamá y que estaban perdidos en el espacio. Mis reservas de dinero no eran malas, pero su mamá hizo otra tontería de las que acostumbra, tuve que levantar denuncia penal, y al mismo tiempo me urgía comprar casa. Las prioridades por orden eran comprar casa antes de las elecciones para no tener efectivo, la segunda era que mi hijo entrara a la preparatoria y pasar su examen, y la tercera que su mamá no saliera con una de las que acostumbraba. Así que eran tres cosas que tenía que hacer en una ventana de tiempo corta. Literalmente obtener escritura de casa a comprar en menos de cuatro meses, es literalmente carrera con el tiempo. Era urgente y medianamente importante.

Otro ejemplo. En un momento dado de 2018 pasaron tres cosas a la vez relativas a programación y me enteré en dos días. El cliente principal necesitaba un cambio de inmediato para manejar parte del empaque antes del viernes de manera diferente. Eso pegaba en inventarios, costos, hojas de Excel que generaba mi sistema. El cliente de las gasolineras le cambiaron la interfaz de un día para otro. Dos días después su SCADA de consumo de gasolina no iba a funcionar. Hacerlo de cero en C# por las complicaciones. En Eve avisaron como con cinco días de anticipación que iban a quitar CREST y pasar a ESI/OAUTH, eso le pegaba a todo el sistema que hice para controlar reembolsos en la alianza de pilotos del juego. Tenía que hacer las tres cosas en la misma semana, porque si no la producción se paraba, los inventarios de gasolina se perdían y los pilotos con bajos recursos no podían obtener sus reembolsos para comprar otra nave cuando eran destruidos en operativos de la alianza. Ninguna de las tres cosas era tan urgente ni tan importante, pero las tres en una semana tuve que decirles a mis hijos y esposa que no estaba preocupado, pero a veces así te pasa en el mundo real. Y sí, resolví las tres cosas en cuatro días con unas 2000 líneas de código entre PHP y C#. Quizá modifiqué unas 600 líneas ajenas de React de la alianza pero no lo tengo presente. Otro caso entonces de urgente versus importante. Y la prioridad fue esa, primero empaques, luego sistema SCADA y por último alianza de Eve.

Y hay cosas que son más importantes. Pero no urgentes. Por ejemplo, cuando murió mi madre descubrí que su vecino estaba loco, probablemente relacionado con grupos criminales, y quería la casa de mi mamá. No era urgente pero sí importante. Otras son inmediatas, cuando el cliente de los monolitos me pide cometer un delito, era urgente, importante e igual carpeta de investigación. Lo mismo con actos hostiles de la madre de mis hijos. Y otras cosas son lógicas. Simplemente no salir de casa cuando no tienes que hacerlo. En este momento estoy bien de dinero, mejor que en la pandemia que mis ingresos bajaron a 28% de lo normal. Con el no pago y similares de este año, pues mis ingresos andan como al 60% de lo normal, pero es varias veces lo que gana mi hija, y más de dos veces lo que ganaba la dama Margarita. Así que urgente no es, importante sí es, pero hacer un movimiento de momento no es necesario, y aquí viene una analogía interesante. Space Invaders y Frogger, o el juego de la ranita que trata de cruzar la calle.

Tengo pocos pendientes ya en este momento. Uno es una tarea que quieren a mano para la licenciatura en contaduría, que me va a tomar varias horas, en hojas tabulares que ya compré y es para el jueves. Es importante pero no urgente. Otro pendiente con una persona del grupo de las reuniones en el Sanborns Los Azulejos, que importa pero no urge y me toma unas horas, y el tercero es un cambio que se ve venir en el juego Eve Online el próximo martes, y que intuyo es una posible devaluación nuevamente, justo por la época en que salen las ofertas de Acción de Gracias, y eso cambia todo lo que había pensado. Si hay devaluación, algunos planes cambian.

Algunas cosas a considerar en Eve Online:

• Eve es un juego que no perdona y en muchos aspectos no tiene piedad. Por ejemplo, despegar con un titán de una base en lowsec ya no puedes entrar otra vez y puedes perder de manera definitiva una nave de 28 mil pesos, 1400 USD, solo por despegar.
• En la vida real algunos te odian por ser lo que no pueden ser. Me pasó con la secta destructiva que trataba de vender cursos a mis conocidos de buen nivel económico, o con personas que se enojaban con clientes porque yo ganaba el doble o era más rápido y fuerte o las tres cosas. En Eve puede pasar por el estilo. Sacas una nave que no pueden pagar, por ejemplo no mucha gente tiene Jump Freighters, Nightmare o Machariel,  te buscan porque en el juego pueden destruirte.
• Muchas reglas de cortesía y ser tranquilo no aplican, pero usando un ejemplo: no me voy a poner en la vida real a insultar a desconocidos, o por ejemplo mi hija de 19 mañana tiene que bailar en fiesta del trabajo pero no ha practicado lo que le enseñé y de la escuela de baile. Es correcto ayudarla, pero también es de sentido común y cortesía tener el material listo, y bañarme otra vez antes. Vamos a acabar cansados de una o dos horas de práctica, pero es lo correcto. Si piden ayuda la damos. Pero la cortesía en Eve es evitar que otros tengan problemas. Así como en la vida real tengo entregables, tengo negocios de industria en Eve y clientes establecidos a los que por lógica les aviso que los precios pueden variar si cambia demasiado el precio del Nocxium, mineral del juego. La misma cortesía básica de decirle sí a mi hija, bañarme y preparar todo, y en el mundo real de avisar a los clientes que los precios cambian si el dólar sube de 22 MXN por USD.

En los 80s Tuvimos problemas en Guadalajara con vecinos. Principalmente por ser de CDMX y que la esposa de mi papá estaba de buen ver, rubia y extranjera y yo con una novia morena guapísima de 17. Esto aplica porque por el simple hecho de existir puedes tener problemas con vecinos aunque sean gente bien. Usando el mismo ejemplo, por tus vecinos en Eve puedes tener problemas así que lo mejor es manejar el anonimato y tener pocos personajes identificables. Prefiero vender a un piloto que ha llamado la atención que crearme problemas y en el juego se puede hacer de manera legal.

En Eve ya encontré cómo hacer que el juego se pague relativamente solo aunque lo tengo pagado por varios años. Cada cinco años vendo uno de los tres personajes de cada cuenta y lo convierto en tiempo aire, así que pago 400 MXN por cuenta cada cinco años. Esto tiene el efecto que me deja con dos espacios por cuenta. Uno de los tres personajes se usa para mantener la cuenta casi gratis. Considerando que hago tratos con cinco grupos de conocidos, que son cinco de mis personajes importantes lo obvio es poner los otros cinco de diez que me importan en esas cuentas. Pero solo funciona en situaciones perfectas. Tengo ideas pero son planes de contingencia, como aprender lenguajes de programación.

A veces haces cambios de trabajo o empiezas una relación de pareja. Porque debes hacerlo. Sin planes de contingencia.

Tengo unos 60 personajes por cosas que me importan de los cuales los realmente importantes son unos diez. La lógica dice tener dos en cada cuenta que sean cinco cuentas y tanto remedio, pero el plan perfecto se destruye si algún vecino se enoja o hay una devaluación. De momento tengo ocho cuentas activas, y hay varias cosas que veo como problemas u opciones que no afecta una devaluación pero no tengo a nadie preparado específicamente para los cambios que empiezan el martes.

Pero a veces ves debilidad estructural en el mundo real o en Eve que van a ser reales y rápido pero no sabes cuándo. Por ejemplo, cuando corté con mi primera novia era obvio pero no sabía cuándo y fue esa misma semana, o en el caso del gerente de ventas que les dijo a los choferes que mintieran a recursos humanos, era obvio que iba a causar problemas, sí, él solito perdió a 40% de los clientes en menos de un mes, y así como cuando manejas sientes que hay que estar atento por algo y te salvas de milagro. Pues así estoy. Veo cambios brutales en la vida de varios, y no es solo el indicador de lo que viene en Eve. Estoy usando Eve Online como símil de lo que veo. Este cambio no me afecta demasiado.

Pero hay cambios brutales que al mismo tiempo son inevitables y no son necesariamente dejarse llevar. He comentado que hay cosas que son como bajarte de un coche que se va a estrellar. A veces vas en el coche y debes dar el volantazo. Tanto el que se bajó, como el que da el volantazo, lo hacen porque piensan que eso evitará problemas mayores. En la vida real dos veces di un volantazo para evitar un choque. Uno en 2003 a 2004 en año nuevo, y evité a una camioneta que venía muy rápido sin luces a las dos de la mañana de año nuevo y que no sé cómo vi. Di el volantazo instintivo. En otra porque manejando a 90 kms por hora, probablemente el 6 de enero de 2000, hubo un choque brutal a 50 o 60 metros de donde yo estaba con muertos y todo y yo iba a 90 por hora. Es decir tuve menos de dos segundos para reaccionar. Eso es una decisión brutal.

Dicen que el hombre, el ser humano tiene cierta fascinación por las alturas. Hay una o dos plazas a las que voy de manera recurrente y apenas me acerco al barandal del piso para dejar pasar a alguien aparecen policías. La gente se mete muchas veces en situaciones estúpidas para sentirse vivo. Soy de los que se bajan del coche cuando el conductor empieza a enloquecer, y realmente ni me subo en coche con conductores raros. A lo que voy, es que los planes de contingencia no te dejan prever todo.

Usando el ejemplo de las naves de EVE clase Supercarrier o titán, naves que valen entre 7 y 28 mil MXN sin equipo y sin piloto, 8 mil pesos 400 USD los Supers y las naves clase Titán son de 206b o 68 meses de juego a 400 MXN, a 28 mil pesos titán y super a 7000 MXN, y son 1400 USD aprox del titán SIN ARMAS y sin piloto que lo tripule, más menos 15% por detalles internos del juego. A lo que voy es que si un descuido, un despegar te puede hacer perder 1400 USD, es un juego donde los errores se pagan caro.

Además, así como te toma años aprender una profesión o construir una relación de pareja, hay errores brutales que te hacen perder tiempo. Nuevamente el hecho de ser previsor y cortés es lo correcto y lo más brutal.

Actualmente un piloto de Eve Online tiene valor por los años de entrenamiento. Cuando vendí mis pilotos grandes valían lo mismo que un titán. En pesos serían 28 mil pesos aprox que usé en tiempo de juego, sin gastar mas que 400 MXN y los cambié por 10 años de tiempo de juego. Considerando que mis recursos en el juego ahora son unos 500 meses de juego ya usados, y los bienes que tengo es el equivalente de 30 meses, a precio normal el tiempo que tengo serían unos diez a 11 mil USD, o unos 240 mil pesos. Pero lo que en realidad he gastado son unos tres años de suscripción, un máximo de 12 mil pesos en diez años. Porque la decisión brutal que hice fue ser previsor y usar planes de contingencia. Puede pensarse que es menos por las ofertas, PLEX y MCT. Pero tengo más o menos lo mismo en PLEX y tiempo aire ya pagado, así que en realidad el valor es el doble, obtenido por lo mismo.

Pero hay planes de contingencia en la vida real. Y en Eve. Prefiero algo duradero y modesto, que una ganancia imposible rápido. En este momento me doy cuenta que tengo que hacer planes de contingencia para el cambio del martes y una idea que tengo, pero eso implica crear cuatro cuentas nuevas. La razón simple es que como dije tengo diez personajes que quiero conservar. Una idea interesante que siempre puedo usar un plan B que usa cuatro cuentas extras, y como dije de las cinco básicas si uno de los tres personajes lo conocen mis conocidos, otro es para pagar la cuenta como dije, no hay mucho margen de maniobra. Por eso de momento tengo ocho, por planes de contingencia anteriores y sin gastar nada.

Pero con los cambios aunque dedique cinco meses a los pilotos a estar listos para hacer algo simple y agradable, no voy a gastar dinero del juego a lo tonto sin considerar los escenarios. Los cinco meses que se tardan en capacitar para lo que quiero es gratis. Así que me encuentro planeando escenarios incluso en esto de cómo distribuir la necesidad de anonimato de Eve, con la comodidad de mis cinco grupos de conocidos, por eso digo que tengo cinco cuentas principales, y eso solo me deja un piloto libre en esas cuentas. A veces es mejor riesgos pequeños que riesgos brutales. Incluso si mi idea no funciona, en un momento dado puedo activar las cuatro cuentas para un experimento con un pase de fin de semana que son como 300 pesos (por las cuatro cuentas o 75 de cada una ) y dejarlas vivas tres días. Menos de lo que pago al ir al cine, o de lo que gasto en la carnicería cada semana.

Y por último, esto me lleva a ver el paralelo de planes de contingencia en Eve con aprender lenguajes de programación en el mundo real. Manejo bastantes más allá de lo básico. Algunos me han salvado el pellejo o me han dado trabajos. Otros simplemente para entender. Los planes de contingencia no son tiempo perdido. A veces despegar en Eve o dar volantazos es desastroso pero a veces es necesario.

En mi caso las decisiones brutales son las que evitan la catástrofe, no las que la provocan

A veces me siento un historiador técnico accidental. Publico esto debido a que creo que es de interés público aunque el documento original sigue vigente.

En el año 2019 hice un documento que mandé al jefe de sistemas de un cliente. Ese Jefe de sistemas era desde entonces, sin que yo lo supiera consultor de ODOO. Este aviso se lo di a el y lo reenvié al director de la empresa en 2021.

Básicamente en medio de un problema en la pandemia en 2021 que estaban viendo reducción de costos, estaban pensando en usar ODOO. Hubo una implementación fallida en 2023 en laque no intervine. Yo ofrecí hacer pruebas en paralelo, pero sabía que era poco probable que funcionara porque el caso de uso era multiempresa, multirfc, y manejar  listas de precios ilimitadas (usaban 47 en 2021 y creo que 25 en 2025 ) , así como controles de venta en piezas y kilos. El sistema EQUIS al que me refiero era un sistema muy chafa que funcionaba por un despacho contable y que en 2021 que yo supiera por las de tesorería ni siquiera funcionaban los catálogos de alta de cuentas para pago a proveedores o contables básicas. Los nombres han sido alterados.

Entre 2019 y 2025, documenté sistemáticamente por qué ODOO no es adecuado para facturación electrónica en México. Cada predicción se validó empíricamente, costando a empresas relacionadas más de $100,000 MXN en implementaciones fallidas. Y eso la pura etapa de planeación. Se pagaron asesorías y horas de implantaciones , y por lo que se los «asesores» les dijeron «tienes que hacerlo solo y si tienes duda de los videos de youtube te cobramos por hora.». En realidad no podían dar soluciones  para las que ODOO nunca estuvo preparado.

El volumen de facturación antes de la pandemia era de 65,000 facturas anuales, que se redujo a 22,000 para 2021 por pérdida de clientes. Mi sistema continuó funcionando sin problemas pese a esta reducción del 66%. Me siguieron y siguen pagando, el costo de mi parte no cambió. EL detalle interesante es que además de eso, realizaba en la lista de época de la pandemia  unas 30 funciones adicionales que antes fueron de los difuntos de Conbranza y contabilidad.

Como dije, En 2023 hubo un intento de implementación de ODOO en la que no participé.  Ofrecí realizar pruebas en paralelo, pero el proyecto no prosperó.

6 Años Después: El Documento Sigue Vigente En 2019 escribí que ODOO «se limpia de responsabilidades al hacer cambios de versión». En 2025:

• ODOO ha lanzado 8 versiones mayores
• Mi documento original aún es válido
• Mi sistema sigue funcionando
• ODOO ha fallado 2 veces en empresas relacionadas No escribo esto para «ganar» un argumento técnico. Lo escribo porque la industria necesita entender: **El software más caro no es el que pagas, es el que te obliga a pagar indefinidamente.**
• Las versiones de ODOO no son «actualizaciones». Son re-implementaciones disfrazadas de progreso. Tu contexto puede ser diferente. Pero pregúntate: ¿Puedo permitirme re-implementar mi ERP cada 18-24 meses? Si la respuesta es no, piénsalo dos veces. — (Y mi sistema de 2014 sigue funcionando)

Cuando evalúes ODOO (o cualquier ERP), no preguntes:
❌ «¿Funciona?»
❌ «¿Cuánto cuesta?»
❌ «¿Es mejor que mi sistema actual?»

Pregunta:
✅ **»¿Qué pasa cuando necesito actualizar?»**
✅ **»¿Cuánto cuesta migrar entre versiones?»**
✅ **»¿Qué pasa si el consultor desaparece?»**
✅ **»¿Puedo cumplir con cambios urgentes del SAT?»**
✅ **»¿Cómo salgo si no funciona?»**

ODOO Community:

• 2019: Implementación en v12
• 2020: v13 sale → v12 obsoleta
• 2021: v14 sale → v12/13 sin soporte
• 2022: v15 sale → v12/13/14 abandonadas
• 2023: v16 sale → Implementación
• 2024: v17 sale → v16 ya vieja
• 2025: v18 sale → v16/17 legacy

• Esto implicaba Mantenimiento: Re–implementación cada 2–3 años Costo: Impredecible (proyecto cada vez) Riesgo: Alto (datos, integraciones, personalizaciones)

En mi caso (2019-2025):
– Mi sistema sigue funcionando
– ODOO ha tenido 8 versiones mayores
– Cada versión habría requerido migración
– Costo estimado: $240k-400k en 6 años
– Mi costo real: Unos 30-40k, no recuerdo, que cobré por el cambio de CFDI 3.3 a 4.0

Y como pregunto siempre que alguien quiere hace un cambio de estos … ¿Cuál es el plan de contingencia?

Resumen parcial de problemas probables por limitaciones de EQUIS el 4 noviembre 2019.
Este borrador es de uso interno, no es versión definitiva, no incluye tiempo de entrega.
Página: 1 de 2

De Alfonso Orozco para Cesar
CESAR Te mando un resumen de lo EQUIS y Odoo para que le comentes a Adrián si quiere
poner EQUIS en la empresa de Puebla.

• EQUIS  como te dije el otro día, depende de una consultoría de una franquicia contable, y
  tienen que levantar ticket hasta para un alta de cuenta bancaria (preguntale a Carolina).
• Odoo No es un software real, avalado por una empresa real. Tienen socios, pero ellos
  mismos no tienen aspecto legal y le echan la bronca de todo a los consultores. Por lo que
  yo sé, cuando no pueden resolver las broncas legales cambian de nombre del software y
  ya lo han hecho tres veces.
• Odoo En cuanto a los socios o partners hay historias que me sé no muy bonitas (despacho
  de contadores que son PAC creo que en Saltillo, pero roban a los clientes de las consultas,
  otro es Itzaya, conocido mío muy poco fiable y entre los serios CREO que ESTABA SISCON
  pero ya no lo está). Eso es mala señal. Te comento que parece que el método de selección
  de nivel del partner es cuantos cursos han tomado y cuantas personas, pero eso no significa
  que los cursos sirvan o tengan que ver con algo real.
• En cuanto al software de Odoo Te manejan un costo de hospedaje que depende de no
  tener cambios en el código del server. Si los tienes, hay una presencia de costo por revisión
  de código que van a subir y te sale como lumbre, es por línea de código. SI te adaptas a el
  software que bueno, pero cualquier cambio sale bastante más caro. Hacen cambios a cada
  rato que no son compatibles entre versiones, y el mecanismo más o menos es que ellos no
  se hacen responsables del software de terceros (community) y «mejoran» a una nueva
  versión para que no tengas garantía y tengas que actualizar el servicio con ODOO. Por lo
  que se los partners huyen y ODOO no se hace responsable. No hay manera que contrates
  a alguien con experiencia en Odoo o EQUIS en acciontrabajo o occmundial (lo que piden
  sin capturistas que cargaran datos a ODOO, no de sistemas)
• Así de rapidito me vienen a la mente varias cosas que seguramente no hacen ni ODOO ni
  EQUIS, que nadie en su sano juicio espera en nuestra operación. De entrada, te recuerdo
  que no están capturando los datos de los grupos correctamente, capturan mal la remisión.
  Los inventarios así no pueden ser reales.
• Resumen ODOO : A ojo de buen cubero el negocio de ODOO es decir que si, te hacen
  comprar una implementación medianamente cara con costo supuestamente cero de
  módulos que no hacen lo que nosotros necesitamos Es el tipo de cosas que no pueden
  tener casos de éxito, porque nadie hace lo que nosotros necesitamos sin tomar la renta de
  software por usuario, y que todo soporte se pierde al cambiar la versión de community o
  que cambien de nombre de software.
• Resumen EQUIS : Además de los datos técnicos del otro dia de la veterinaria , servidores
  en casa, soporte de 3000 pesos L a V en una plaza comercial, el presupuesto que me
  contaste de EQUIS es altísimo, no se en cuanto saldría para la empresa de puebla de 65 mil facturas al año. Te comento que es un software hecho por un despacho AFILIADO de una franquicia contable. No es un
  software real. Usa protocolos bastante antiguos y para el caso mejor SAE.

Puntos BASICOS que debería comprometerse el consultor:

1. Que la venta se capture en kilos y piezas.
2. Complementarias de CDMX y empresa de puebla, y que autoajuste precios cada dia,
   debe salir a una hora especifica automáticamente.
3. Corrección de peso de empaque y reja aplicada a producto variable , con limite por cliente de
   kilos, autocalculado en base a la venta desde última fecha de envio
4. Ajuste de la señora Guadalupe por 1540 pesos y el de su ganancia.
5. Consulta en línea de los PDF y XML filtrado por rango de fechas, ruta, rfc, y que haga el envió automático de correo del PDF y el XML. Esto es importante para contabilidad, para el cliente y para buscar que paso con una remisión en caso de problemas poder reimprimir rápido la factura.
6.  Niveles de acceso por rutas. Acuérdate que Adrián no quiere que personas que no deban vean la venta de ciertas rutas o clientes. Tampoco deben poder imprimir público en general
7. Multiemisor de emisores fiscales para NC, Rep, facturas y NLCI
8. Emisión de reporte 919 con tablas de semanas para reporte de Adrián
9. Todas las remisiones están asociadas a ruta, vendedor y ayudante? (comisiones)
10. 47 listas de precios
11. Precios forzados
12. Captura de facturas de promoción o degustación timbradas. Esto es importante porque la remisión debe ir ligada a una factura y a los clientes les regalamos cientos de kilos de producto a la semana. Tienen un efecto fiscal en la salida de inventario al darle al cliente.
13. Que la captura de fichas bancarias solo permita aplicar a la persona que creo la ficha, y solo facturas de la misma razón social que es el depósito bancario.
14. Cancelaciones de fichas bancarias, que implica reps y similares
15. Ajuste de centavos (cuando pagan de más y pagan de menos ¿cómo cierran la ficha bancaria?)
16. Emisión de NC y reps extemporáneos con modo de pago y uso diferente como quiere Garis
17. Emitir formatos de remisiones para que se lleven los conductores
18. Inventarios en kilos y piezas y control de totales en ventas de kilos y piezas variables. (venta del día)
19. Clientes que un día si y otro día no, son público en general o a su rfc
20. Módulo de pedidos con conversión de kilos a piezas y viceversa, por sucursal y reportes de no surtido

Antes que te hagan la propuesta, tienen que darte una garantía por escrito los
consultores de que haga por lo menos los puntos anteriores, cúbrete las espaldas o
pasa lo que les pasó en DYNAWARE.

Actualización Noviembre 2025:

Mi sistema de 2014 sigue funcionando. Ha procesado más de 850,000 facturas en 13 años. Sobrevivió una pandemia que mató al 66% del negocio. Absorbió funciones de dos departamentos que desaparecieron. Se actualizó a CFDI 4.0 sin drama. ODOO ha lanzado 8 versiones mayores desde mi documento de 2019. Los 20 puntos técnicos que pedí entonces siguen sin tener respuesta de ningún consultor ODOO que conozco.

Otro punto interesante era el modelo de negocio. Se usaban unas 47 listas de precio y es un buen punto 21

• 21 El sistema original usaba en las listas de precios precios relativos (deltas: -3, +5) no absolutos. Con 16,000 excepciones para 5,000 clientes. En dos semanas, de lista de precios diaria, migré gradualmente las excepciones a precios fijos, hice lista de precios por grupos  y reduje excepciones a 160 (reducción 99%) mientras hicimos unas tres mil facturas. Todo sin parar el sistema. ¿Un consultor ODOO puede garantizar una migración así? ¿O te va a decir «paramos todo y reimplementamos»?
• 22 . En 2019 las personalizaciones de ODOO 12 (2019) se hacían con @api.multi que ya no existía en 2020 en ODOO 13. Tuve que rescatar varias personas en pandemia por eso.

Y sigo preguntando lo mismo: ¿Cuál es el plan de contingencia?  Odoo no lo tenía y si no funcionan las cosas desde el día uno mas te vale tener documentado lo que se comprometieron los consultores o haber hecho lo que yo: «Ofrezco apoyar en las pruebas en paralelo»

Hay un documento previo interesante en este enlace

De ERP Fallidos

 

Hace unos años, le respondí a un practicante del camino rojo que estaba tratando de cambiar el mundo, que para cambiar el mundo, necesitas un gran pañal.

Me encuentro en una situación en que encuentro muchas personas con los beneficios de educación formal y valores, que usando usando una metáfora son parecidas a las vacunas.

Te previenen de problemas mayores de manera definitiva.

Puedes tener título y no tener idea de leyes. Eso lo he visto. Incluso de licenciados en derecho.

Pero … las leyes de la naturaleza dicen que hay cosas que no tienen remedio, y las leyes médicas dicen que hay cosas que pueden curarse de manera definitiva o casi. Por ejemplo una gripa. Pero el covid o una fractura de hueso, solo tienen tratamientos, no curas permanentes y por lo general hay secuelas.

A mar revuelto ganancia de pescadores dicen. En estados unidos hay movimientos anti vacunas. Pero el problema está en que las personas prácticas piensan en curas o tratamientos. Otros en su ganancia solamente. Ejemplo, no creo que existan vacunas contra el cáncer como dicen personas conspiranoicas. Pero evito comer cosas que se que me hacen daño. Hay una prevención. Evito azúcar (solo en refrescos y pastel ocasionalmente), sal no pongo extra y evito harinas como la del pan dulce.

EL problema es que hay empresas donde el tratamiento no es posible. Debe quitarse, amputarse, despedirse a personal que no funciona. Incluso renunciar si el problema es la empresa o los superiores. He comentado situaciones donde la cura empieza por aceptar el problema. Pero es una cuestión incluso un poco retorcida. Si una persona de los monolitos me dice que no baja nada su deuda de casa en UMAS al 6% , y revisado, pues claro. Solo ha pagado el mínimo y cada año le suben unas 1200 UMAS en ajuste, por lo que en realidad paga el 14% o más. Es un síntoma. La cura es pagar. El tratamiento es pagar cada mes mas de lo necesario.

Quité un párrafo . En realidad el problema que comentaba ayer de complicarse la vida es relevante aquí. Con el problema de los monolitos retrocedieron unos cinco años en tecnología y con lo que estaban pagando no pueden contratar a alguien que arregle su desastre auto provocado. Si no pagas el servidor, pues desaparece. Literalmente los pagos a tiempo son un paliativo, pero si se descompone la luz de tu coche o se funde un foco, lo cambias. Ese no era el caso aquí. No solamente se crearon un problema donde no lo hay. Sino que no hicieron cura ni tratamiento. Solo decidieron condicionar el pago a cometer un delito. Eso es mas parecido a tratar de suicidarse y sobrevivir de milagro, pero no es tratamiento ni cura.

De momento veo personas que hacen «suicidios emocionales» y «suicidios laborales» desde hace años. Pero decidir empezar un negocio «sin vacunas»  o procesos de desarrollo hoy en Java Faces o JavaEE, o el mismo REACT para problemas medianos o grandes, es literalmente un problema mediano o grande que antes no había. Me preguntaron hace unos días de mi manejo de TOMCAT. Claro. No hay problema. Lo uso desde 2002 mas o menos. Pero quieren hacer máquinas virtuales de 2 gb de ram con TOMCAT. Es como ponerle media tonelada a una bicicleta. No va a funcionar.

De momento se que la solución práctica es trabajar sobre lo que ha sido dañado, diría el iching, pensar en curas y tratamientos para problemas específicos. Es decir soluciones temporales o definitivas. Pero en el entorno que veo, asi como la entropía puede hacer parecer buena idea pedirme cometer un delito o no pagar a las dos analistas mas eficientes como la dama margarita, es para fines prácticos lo mismo de querer mover un mueble de media tonelada en una bicicleta.

Son proyectos que no van a funcionar. Diría El iching que se rompen los ejes de la carreta. Así como parte del gobierno actual de USA es antivacunas, es un poco tonto que lo que está a veces detrás de proyectos como tomcat en 2 gb de ram, o el no pago de servidores es exactamente algo parecido al hospital de servicio social que no tenía extinguidores funcionales una sola computadora y no quería pagar a los proveedores. Una mezcla entre jenga corporativo y antivacunas empresarial. En los monolitos, mi trabajo tenía que ver con información confidencial y si de por sí era ridículo que retrasaran el pago, mas ridículo condicionar el pago a cometer un delito.

El colapso de «los monolitos» fue consecuencia de su propia mala gestión, no de que la dama Margarita y no nos negáramos a ser explotados  ( por separado en momentos diferentes)

• Contexto: A los 50 años decidí retomar la licenciatura de los años 90, que no me dieron el título por cuestiones de revalidaciones de ciudades diferentes. Aunque desde 1991 he trabajado en sistemas y DevOps con clientes de alto nivel, nunca me titulé por cuestiones administrativas a pesar de haber concluido servicio social y con un promedio de 9.7. En 2025 estoy por terminar la carrera de contaduría, más como negocio alterno y ejercicio de validación que por necesidad laboral, con la intención de tener un plan C y ofrecer a mis clientes actuales otros servicios, apoyado en más de tres décadas de experiencia en sistemas y lo que sé de contabilidad desde los 90.

Entre que se deciden cosas de clientes, me encuentro en uno de esos momentos de la vida donde debes dejar pasar cosas pequeñas como paso previo para una mejor negociación y afortunadamente ya casi acabé. Me faltan uno o dos detalles pequeños extras pero me debo dar un descanso.

En los últimos meses he seguido con lo de licenciatura y una maestra nos pidió entregar unos cálculos de impuestos a mano. Pobre. No se si le entienda, pero mañana me tengo que lanzar a comprar hojas tabulares. AL empezar la carrera por segunda vez en esta escuela, realmente no se han refrescado mis conocimientos, solo vi algo nuevo con un libro de derecho laboral con historia de la época de Flores Magón. Pero hubo una materia a principios de la carrera, creo que en el segundo bloque… de cálculo vectorial y multiplicación de matrices. El examen fue una bestialidad y a mano por zoom. Creo que lo peor para la maestra fue traducir lo que escribí. Y como resolví parte del otro examen por logaritmos (porque no había manera de hacerlo con lo que habíamos visto) me hizo acordarme del manejo de operaciones de matrices.

Por un lado, es cierto como dijo un maestro de la carrera hace años que puede servir para sistemas pero eso es como estructura de datos, no por cálculos.  Literalmente es calcular peras por manzanas. Si bien los despejes de fórmulas y simplificaciones son parte de mi vida desde antes de la lógica simbólica, la idea de el algebra es que hay dos soluciones posibles en las ecuaciones de segundo grado.   En realidad es una y rara vez son más. O pagas la luz o te lo cortan. O vas al baño o mojas tu ropa. En realidad el cálculo vectorial y las matrices NO son simplificación y son terribles para proyectos concretos, que te puede dar mayor velocidad usar regla de tres y las matrices y sus operaciones son NECESARIAS para reconstruir la civilización o en casos de colapso de comunicación  o efecto carrington (llamarada solar gigantesca del siglo XIX)  pero lo que veo son dolores de cabeza muchas veces porque tratan de meter una variable nueva que solo ensucia el agua. Algo así como deber de una tarjeta de crédito y sacar otra nueva para pagar la anterior. Meter nuevas ecuaciones parece simple hasta que te das cuenta que  ahora en lugar de un problema, tienes dos.  Simplificaciones o métodos que funcionan en papel, pero que en proyectos reales pueden ser trampas y con efectos secundarios desastrosos.

Y eso les ha pasado mucho en lugares que conozco. Resuelven un problema que yo a veces desconozco y se crean tres o cuatro problemas a la vez. Son cosas para pensar. Por lo general no me agoto y estoy tranquilo, pero muchas veces lo que falta es sentido común.  Es sabido el problema de los MBA, expertos en administración en diversos países que maximizan la ganancia a corto plazo destruyendo a medio o largo plazo. Otras personas cambian los problemas por otros para ganar tiempo, y se pasan su vida llena de problemas por jugar sucio y hacerse tontos solos. Los resultados de esas cosas son acumulativos y además de quedarse solos, muchas veces se llevan los resultados de su empresa o departamento por delante, aunque los resultados se ven mas en su vida personal de manera inmediata. Rara vez verás a alguien centrado, pero que sea cortés y amable hacer ese tipo de tonterías. Y los que cambian un problema por otro, están viendo como justificar resultados con trampas o simplemente pasando el problema a otra persona tratando de ganar tiempo.

Lo que me tiene tranquilo es que siempre pienso a largo plazo y no me creo problemas innecesarios en la vida real, evitando cosas urgentes. Así que los pendientes que tengo son «importantes» pero no urgentes, como el cuadro de decisiones de Eisenhower, pero no tengo prisa. No voy a vectorizarlo creándome problemas nuevos

Moraleja: No complicar lo que puede resolverse con sentido común.

Este es un ejemplo del que me acordé hoy y es relevante a lo que está pasando con la Inteligencia artificial, el mercado de desarrollo de software y los proyectos imposibles a los que en sistemas a veces se les llaman Death march Run. Y aunque los saques, se enojan.

Estuve en una preparatoria que llevaba divididas las clases en dos partes, tres días a la semana en áreas generales y tres días a la semana en lo que llamaban «las áreas» o adiestramientos, por Gobernador Curiel menos para los de industria.

Siempre fui muy bueno en química. Incluso en un examen de orientación salió en sexto semestre que era mejor candidato para contaduría e ingeniero químico que cualquier otra carrera. No existía sistemas en 1990. Solo comunicaciones. Pero …

Esta historia puede resumirse en varios pasos.

• Usábamos unos libros de química con un exámen integrado o cuestionario, creo que de editorial CECSA, que era cada año de unas 600 a 700 preguntas o más.
• En Los laboratorios había un «director de quimica» que era el que daba ordenes a todos los maestros de Quimica. Se apellidaba Martín del Campo, Prepa 6 UDG.
• Martín del campo desde que entramos se llevaba muy bien con los de el Grupo E. Yo era del grupo C. A nosotros no nos daba clase directamente.
• Por alguna razón que no recuerdo se iba a hacer un torneo de química de tres personas por equipo. Y por alguna razón nos interesaba ganar el torneo a algunos del grupo C .
• Teníamos dos ventajas. Una era una chica apellidada Isawa, morena, de buen ver y distraída que contestaba a todo lo de química de manera natural como si fuera obvio, mala en otras materias pero buenísima para eso. La otra ventaja era yo. Buena memoria y organizado. Asi que con un compañero RCH, que ahora es abogado, nos inscribimos.
• Como preparación al torneo, los tres por separado llenamos los tres cuestionarios de los tres años, del libro. Solo hubo una pregunta que no venía explicada en el libro.
• Que es el agua pesada ?
• Yo recordaba que tenía aplicaciones nucleares y que era tóxica pero poco más. Asi que nos fuimos a la universidad a preguntar los tres que era Agua pesada a maestros de la licenciatura o ingeniería. Ni buscamos en libros.
• Que yo recuerde fuimos unos 12 equipos. Al final quedamos dos, Erámos nosotros contra el grupo E. Ya estaban descalificados y vencidos los de la otra sección, y los dos turnos matutinos. Las eliminatorias fueron sencillas. Me acuerdo de Isawa con su voz aburrida destruyendo al equipo contrario en los dos últimos rounds.
• El formato permitía hacer una aclaración cuando una respuesta estaba mal para subir el puntaje. El ultimo round eran dos preguntas de cada lado.
• Empiezan con nosotros.
• Primera pregunta … que es el agua pesada ?
• Respondo yo con lo que nos dijeron los maestros de la universidad. Una respuesta de dos minutos mas o menos. Y …
• Respuesta incorrecta !!!! Aclaración ? quien la va a hacer ?
• Yo.
• Mi nombre es Alfonso Orozco. Aquí están las respuestas que nos dieron por escrito los maestros de la facultad de quimica sobre esta pregunta que no estaba en el manual. Por lo mismo, nos dieron la pregunta mas dificil y ustedes son profesionales. O nos estan mintiendo o juegan con reglas alteradas. El Grupo C Vespertino, deja el torneo porque esta amañado. Director, aqui tiene las hojas de lo que nos dijeron los maestros de quimica y las copias que sacamos de libros
• Y nos fuimos.

Así que actualmente me he regido desde hace años por el principio de no jugar con reglas alteradas Pero estoy viendo muchos problemas en ecosistemas y desarrollo de software, no por la inteligencia artificial. Simplemente que ver todo lo que hay que hacer para un EC2 de Amazon que no esté en useast-1 y los peligros al respecto, estamos en problemas serios a futuro de internet porque los ecosistemas se están complicando la vida de manera terrible. Desde problemas de DNS a ineptos en puestos de gobierno, a programas educativos que no enseñan lo real.

Así como dejamos el torneo, a veces la mejor estrategia en sistemas es saber cuándo ni siquiera entrar en un proyecto, como retirarse de un proyecto condenado y documentar formalmente las inconsistencias de superiores, compañeros y empleados. Se trata nuevamente de la idea de realidad sin concesiones.

Estamos en el mismo caso que noté en 2001 Cuando todo el mundo estaba terco en asp , iis y active documents.

Hace muchos años aprendí que la documentación de un sistema de programación debe mantenerse actualizada, y que el código «vivo» tiene cambios. Me parece que empecé a darme cuenta de eso en asuntos legales, también, allá por 1994. Por razones largas de explicar estaba trabajando ya en una segunda cadena de supermercados, teniendo un rol doble entre seguridad y mi puesto oficial. Y por seguridad me refiero a mi capacidad de detectar fraudes. Eso lo hacía en oficinas centrales de recursos humanos, que en ese entonces estaban por Vallejo.

Una de las cosas que hice fue colaborar con dos o tres sugerencias en el reglamento interno de los trabajadores, y además di una revisión casi final sobre ortografía. El borrador final estaba diseñado para ser usado en trípticos, y no era demasiado grande. No quiero ni pensar la aberración actual que debe ser en cuanto a largo. El caso es que en un momento dado, tenía un conocimiento más que estándar del mismo, y cuando en 1995, a principios de febrero, el gerente de la sucursal se dio un tiro en el pie figuradamente hablando, una de mis defensas más fuertes era el conocimiento del reglamento. Ese gerente echó a la basura los bonos de todos los de gerencia (tres o cuatro) y del gerente de zona de todo un año, en un solo día al impedirme hacer mi trabajo. Él no sabía cómo se calculaban sus bonos.

Cuando tres o cuatro días después llegó el gerente de zona a saber qué había pasado, porque yo seguía terco en mostrar que lo que querían hacer estaba prohibido por el reglamento y era de mala fe, llevaba yo como tres días de no hacer mi trabajo sino de apoyar a recursos humanos. No podían hacerme trabajar en lo mío y el apoyo a la de Recursos Humanos era súper bienvenido (básicamente con entrevistas de contratación y exámenes psicométricos). La cara del gerente de zona fue memorable. Y fue la primera vez que me dieron una gerencia definitiva formal. Ya había realizado esas funciones de gerencia durante años, pero resultaba más valioso en el área de sistemas. Y el error es que al no realizar mi trabajo de sistemas, salía afectado el bono de los gerentes de esa tienda, los de otras catorce o quince sucursales y del gerente de la zona responsable y otro gerente de zona extra.

Lo importante de esta historia es el efecto secundario que fue la promoción y la pérdida de bonos ANUALES de unas 50 personas.

En aquella época tenía yo varios sistemas bajo Turbo Pascal con records y objects; no se usaban Bases de Datos ni siquiera dbf; clipper era algo que estaba tratando de impulsar desde unos dos años antes. Solo que ese método  de records era muy latoso de hacer cambios a la estructura de datos. Muchas veces era preferible crear archivos secundarios en lugar de campos nuevos. En realidad, tuvo que ver esa etapa muchísimo en mi experiencia de los pros y contras de algo llamado Normalización. Sin meterme en detalles… muchas personas piensan, por ejemplo, que si tienes choferes y una ruta de reparto, los choferes deben ir en la ruta, pero en realidad no. Deben ir en el reparto del día por comisiones, incapacidades y faltas. La normalización excesiva causa problemas mucho más fuertes de los que parecen.

En 2006, aproximadamente, acababa de nacer mi primera hija y empecé a trabajar en una industria, pero no querían que le hiciera cambios al mismo sistema pasado ciertas cosas. Nada de iniciativa propia o áreas de mejora. En realidad era un problema fuerte entre dos grupos «políticos» de funcionarios que se saboteaban solos. Los cambios sí los hice por iniciativa propia, menos en los procesos que querían el control absoluto, que fueron los procesos que fallaron después más feo. El punto de vista era: «déjalo como está; sabemos que los programadores le mueven cuando no hay que hacerlo ya». El efecto secundario de no estar actualizado es que los errores que no corriges cuando se puede se hacen más grandes. Una especie de recargos en la operación y nada que ver con «deuda técnica». Más adelante en la empresa de comunicaciones vía satélite hice un sistema de cero en tres meses,  al cuarto mes me pasaron a proyectos especiales cuando me negué a trabajar con una contadora que mentía y que supervisaba factura electrónica. Y aunque la corrieron, pusieron al amigo de un socio que comentaba en otras entradas del blog  que se la pasaba en la guitarra eléctrica y él no hizo nada durante casi dos años y medio. Así que de repente tenían mi programa instalado en cientos de clientes, pero sin actualizaciones de los dos años, ni había nada de las cinco a siete áreas de mejoras/requerimientos de cuando me fui a proyectos especiales. Literalmente, además lo instalaron en cientos de máquinas virtuales con clientes y no tenían ya las llaves o claves de acceso. Su solución fue pedirme que hackeara 200 máquinas de clientes, porque aunque conocían mi código y podía exportarse por SOAP la base de datos, no querían aceptar lo sucedido. Primero querían dejarlo como está y luego «No querían dejarlo como está», que corrigiera y regresara al problema original. Su idea era que corrigiera los errores, los pusiera en nueva versión en máquinas virtuales de las que no tenían llave y respaldo (y que por muchas razones no podían actualizarse solas sino bajo demanda por estar en instalaciones del cliente y en un principio el proyecto era que solo 2 estuvieran con cliente y el resto en nuestro servidor. La realidad era como siete clientes en nuestro server y 200 a 300 en virtualización con la versión de dos años antes.  ). Me fui porque querían que violara la ley, que lo hiciera gratis, y que corrigiera yo solo en tres semanas el error de cinco personas durante casi tres años y se llevaran ellos el mérito. Coincidió con una muy buena oferta en lo que ahora llamo el cliente problemático. Todo por el «dejarlo como está».

El peor sistema que he visto en legacy es actualmente el seudolaravel 5.2 de los monolitos sobre php 5.6, con hardcoded y puertos cerrados. Ese sistema lo reescribí en base a requisitos funcionales en dos meses. Que yo recuerde del original, ponía siempre mal la «institución origen» ( hardcoded )y ponía una institución alemana, y encontrar cómo y dónde poner el correcto fueron unas 170 líneas de código. Y decidieron no usar mi sistema. Y perdieron el otro por falta de pago de los servidores. Sin comentarios.

En cuanto a lo que viene al caso, es porque recientemente he sido contactado por ofertas de personas o empresas que usan REACT, un framework sobre NODE de 2013. Problema serio: CRA no tiene soporte desde junio de este año, y los use effect y mal uso de los hooks hacen terrible la depuración. Oficialmente es una biblioteca que algunos confunden con un sistema de programación, y además usan para router next.js casi siempre. Pero después de ver varios repositorios de código de 2013 para acá con problemas y confusiones no solo entre versiones, sino entre los protocolos http/https, me pregunto si todos los que cambiaron de angular 2 en adelante a otro lenguaje lo hicieron a React o qué.

Sí, es posible que se puedan hacer partes más eficientes con React, pero en un equipo de varios programadores que se consideran serios, el uso de efectos / useeffects y hooks hacen varias cosas inmantenibles. Y mira que lo dice alguien que ha manejado proyectos de decenas de miles de líneas en c# y .net de versiones mixtas con algo de Xamarin.

Ese caso sí es un «déjalo como está». Si el responsable en entrevista técnica NO SABE qué React está usando, lo he dejado por la paz. Esto no se ve bien a futuro, no por mí, sino por todos esos proyectos. TypeScript y vue.js parece ser lo más decente del mercado que no se inclina por lo .net, pero solo pensar en usar React en manejo de factura electrónica o de información de blobs me da escalofríos.

Para aquellos ajenos a React o a quienes el framework les resulta incomprensible, mi experiencia indica que la mantenibilidad y la depuración en equipos grandes o proyectos grandes es inexistente o insostenible, proyectando su declive en el largo plazo (10 años), principalmente por problemas inherentes al use effect y a la dependencia excesiva de librerías de terceros. Mientras que proyectos de 70 mil a 1 millón de líneas (LOC) son estándar en otros lenguajes, en React el manejo de sistemas que superan las 15 mil líneas resulta, …. interesante.

En sistemas críticos, la mantenibilidad no es un lujo: es la diferencia entre continuidad y desastre. Y frameworks como React, mal usados, pueden ser el principio del desastre.