00:00:07 Importancia del diseño de software en supply chains modernos.
00:01:22 Problemas comunes de diseño de software en la gestión de supply chain.
00:02:37 Desafíos de los sistemas de software en tiempo real en supply chains.
00:04:55 Cómo las operaciones complejas pueden impactar los sistemas en tiempo real.
00:07:13 Sistemas en tiempo real congestionados por operaciones que no son en tiempo real.
00:09:13 Importancia de las decisiones de diseño y la escala temporal en el software de supply chain.
00:12:31 Diferencias entre software single tenant y multi tenant.
00:14:11 Desafíos con múltiples versiones de software en aplicaciones single tenant.
00:15:33 Ventajas del software multi tenant y el cambio hacia modelos SaaS.
00:17:56 Importancia de comprender los supuestos fundamentales en el diseño de software para profesionales de supply chain.
00:19:18 Supuestos fundamentales de diseño de Lokad, incluyendo el modo de procesamiento por lotes y la multi-tenancy.
00:21:35 Reflexiones finales sobre comprender las decisiones en el software y su impacto en las operaciones futuras.
00:23:36 Reflexiones de cierre.
Resumen
En una entrevista con Joannes Vermorel, fundador de Lokad, se discute el impacto del diseño de software en la optimización de supply chain. Los desafíos a menudo surgen de problemas de diseño más que de bugs o fallos, lo que puede hacer que el software sea lento, poco intuitivo y difícil de configurar. El manejo de datos en tiempo real es una característica clave que puede impactar las operaciones. Sin embargo, centrarse en operaciones rápidas y simples puede obstaculizar procesos complejos como el forecast o los análisis a nivel de red. Es crucial comprender los supuestos del diseño de software para evitar que surjan problemas debido a desajustes entre el diseño del software y el uso previsto por una empresa.
Resumen Extendido
En esta entrevista, el presentador Kieran Chandler discute con Joannes Vermorel, el fundador de Lokad, el impacto del diseño de software en las operaciones de la empresa, particularmente en el contexto de la optimización de supply chain. Vermorel destaca la importancia del diseño de software en supply chains modernos, que dependen de múltiples capas de software, como ERPs, MRPs, WMSs, OMSs y EDIs, para funcionar eficientemente.
Los desafíos que enfrentan los clientes de Lokad a menudo se originan en problemas con el diseño de su software, más que en bugs o fallos evidentes. Estos problemas de diseño pueden hacer que el software sea lento, poco intuitivo y difícil de configurar. Como explica Vermorel, estos problemas a menudo resultan de un desajuste entre las decisiones fundamentales de diseño tomadas para el software y la realidad actual de la supply chain a la que está destinado.
Una de las características clave de la arquitectura de software que puede impactar las operaciones de supply chain es su capacidad para manejar datos en tiempo real. Vermorel señala que, si bien el procesamiento de datos en tiempo real verdadero no es posible debido a la velocidad finita de la luz, muchos sistemas de software de supply chain están diseñados para aproximar el procesamiento de datos en tiempo real. Por ejemplo, cuando se retira un artículo de una estantería, el software decrementa el nivel de stock inmediatamente. Sin embargo, este enfoque en tiempo real puede tener consecuencias inesperadas.
Cuando el software está diseñado para operaciones rápidas y simples, se vuelve desafiante ejecutar operaciones más complejas, tales como el forecast o análisis a nivel de red. Estas operaciones complejas requieren un nivel más sofisticado de procesamiento de datos, lo cual puede no ser factible en un sistema optimizado para actualizaciones en tiempo real a pequeña escala.
Joannes Vermorel enfatiza la importancia crítica del diseño de software en la optimización de supply chain. Los desafíos que enfrentan los clientes de Lokad a menudo se originan en problemas de diseño que hacen que el software sea lento, poco intuitivo y difícil de configurar, resultando de un desajuste entre las decisiones fundamentales de diseño del software y la realidad actual de la supply chain. La capacidad para manejar datos en tiempo real es una característica clave de la arquitectura de software que puede impactar las operaciones de supply chain. Sin embargo, cuando el software está diseñado para operaciones rápidas y simples, se vuelve difícil ejecutar operaciones más complejas, tales como el forecast o análisis a nivel de red, que requieren un nivel más sofisticado de procesamiento de datos.
Vermorel explica que los problemas a los que se enfrentan los profesionales de supply chain que usan dicho software no siempre son obvios, ya que a menudo se manifiestan como una lenta acumulación de inconvenientes, a lo que él se refiere como “muerte por mil cortes.”
Un problema clave es la necesidad de funcionalidad en tiempo real en ciertos escenarios, como escanear artículos en una cinta transportadora de alta velocidad. Cuando se introducen operaciones que no son en tiempo real en el sistema, el rendimiento general puede verse afectado negativamente, resultando en ralentizaciones y demoras. Esto puede conllevar a una mayor frustración entre los usuarios y a una reducción en la eficiencia.
Vermorel destaca la importancia de tomar las decisiones fundamentales de diseño correctas, las cuales deben estar profundamente alineadas con los problemas que el software intenta resolver. En el contexto del software de supply chain, se asumen varios supuestos fundamentales, y si estos no se cumplen, pueden surgir problemas más adelante.
La escala temporal en la que opera el software es una consideración crucial. Vermorel describe los diferentes tipos de software necesarios para diversas escalas temporales, que van desde tiempos de respuesta submilisegundos para el funcionamiento de cintas transportadoras, hasta la planificación a largo plazo que involucra decisiones de ubicación de fábricas que abarcan años o incluso décadas. Cada incremento en el orden de magnitud de la escala temporal requiere un tipo diferente de software con capacidades únicas.
En Lokad, el enfoque se centra típicamente en escalas temporales de un día a un año, lo que requiere un enfoque diferente en el diseño de software. Vermorel también aborda las diferencias entre el software single tenant y multi tenant, lo que es una consideración crítica para los desarrolladores de software, aunque menos conocida para la mayoría de las empresas.
Discuten las diferencias entre el software multi tenant y single tenant, las ventajas del modelo SaaS y los supuestos fundamentales que han guiado el diseño de software de Lokad.
Vermorel explica que el software multi tenant atiende a múltiples clientes utilizando la misma pieza de software, mientras que el software single tenant implica dar a cada cliente su propia versión hecha a la medida. Lokad es multi tenant, con una base de código actualizada semanalmente. Este enfoque tiene varias ventajas, incluyendo un versionado simplificado y menos problemas de seguridad. Vermorel contrasta esto con el software single tenant, que permite la personalización por cliente pero requiere gestionar múltiples versiones, lo que conlleva desafíos operativos.
Observa que, en la última década, muchas empresas de software serias han adoptado la multi-tenancy. Para aplicaciones web como Lokad, ser multi tenant es bastante sencillo, pero para software que opera en las máquinas de los clientes, puede ser más complicado. Una solución a este problema es la estrategia “evergreen”, ejemplificada por Google Chrome y Microsoft Office 365. Estas aplicaciones se actualizan automáticamente, sin intervención del usuario, lo que mitiga los problemas de tener múltiples versiones del mismo software.
Al discutir el diseño de software de Lokad, Vermorel enfatiza la importancia de comprender los supuestos fundamentales de un proveedor. Advierte contra aquellos proveedores que afirman que su software puede hacerlo todo y subraya que el diseño se trata de trade-offs, con aspectos tanto positivos como negativos. Anima a los potenciales clientes a preguntar a los proveedores de software acerca de sus supuestos fundamentales y a ser cautelosos con aquellos que solo ofrecen respuestas vagas y positivas.
Los supuestos fundamentales de diseño de Lokad incluyen el modo de procesamiento por lotes, el cual, según explica Vermorel, se elige porque permite una mejor optimización y gestión de recursos.
Un principio clave es priorizar cálculos inteligentes sobre la velocidad. Lokad prefiere tener cálculos precisos y detallados, incluso si toman más tiempo, en lugar de cálculos más rápidos pero menos precisos. El software está diseñado para el procesamiento por lotes en lugar de en tiempo real, lo que permite una mayor expresividad y capacidad en el análisis.
Otro supuesto fundamental es la importancia de la multi-tenancy y de aprovechar las capacidades que ofrece la computación en la nube. Lokad aspira a usar capacidades de scale-out en lugar de scale-up, lo que significa que utilizan múltiples máquinas más pequeñas para procesar grandes cantidades de datos, en lugar de depender de una única supercomputadora potente.
Vermorel enfatiza la importancia de que los profesionales de supply chain comprendan los supuestos fundamentales de diseño de su software. Este entendimiento ayuda a prevenir problemas que surgen de un desajuste entre el diseño del software y el uso previsto por la empresa. Los proveedores pueden afirmar que su software es versátil y adecuado para diversas situaciones, pero en realidad, ciertas limitaciones de diseño pueden obstaculizar su efectividad en algunas aplicaciones.
Transcripción completa
Kieran Chandler: Hoy, vamos a entender cómo estas decisiones pueden terminar encajonando a una empresa y también comprender algunos de los supuestos fundamentales que se esconden detrás de ellas. Entonces, Joannes, estamos hablando un poco sobre cómo un mal diseño de software puede impactar realmente a una empresa. ¿Cuáles son algunos de los desafíos que ves?
Joannes Vermorel: El primer desafío es que el diseño de software es de vital importancia para supply chains. Las supply chains modernas funcionan con software. Tienes camiones, máquinas, cintas transportadoras, pero también grandes porciones de software como tu ERP, MRP, WMS, OMS, EDI, y tantas capas. Las supply chains modernas no funcionan sin software en grandes cantidades. Cuando hablo con los clientes de Lokad, frecuentemente luchan contra el paisaje aplicativo de la supply chain. Hay muchos problemas relacionados con el software, pero no necesariamente son bugs o fallos. Los problemas de diseño son mucho más omnipresentes; hacen que las cosas sean lentas, poco intuitivas y que el sistema tarde una eternidad en configurarse. Cuando intentas hacer un análisis de causa raíz, frecuentemente observas que los problemas son, en realidad, problemas de diseño de software en los que se tomaron decisiones fundamentales sobre el diseño del software y que simplemente no se ajustaron en absoluto a la realidad actual de la supply chain en cuestión.
Kieran Chandler: Entonces, ¿cuáles son algunas de las características de la arquitectura de software que pueden ser tan importantes? ¿Cuáles son algunos de los desafíos que has observado con tus clientes?
Joannes Vermorel: Digamos, por ejemplo, el tiempo real. Muchos software de supply chain hoy en día están orientados a operaciones en tiempo real. Con tiempo real, me refiero a que si decides tomar una unidad del estante, el nivel de stock se decrementa inmediatamente. Parece algo muy razonable. Sin embargo, en cuanto tienes este tipo de software diseñado para tiempo real, cualquier cálculo sofisticado va a ser un gran dolor de cabeza para operar en el software. La razón es que, si tu software está diseñado para ser súper rápido en operaciones súper simples, tener una operación compleja, como un forecast o un análisis a nivel de red, va a ser una lucha. Esto se debe a que tu software está diseñado para operaciones muy ágiles y pequeñas, y cuando necesitas procesar una cantidad moderadamente compleja de datos, se vuelve difícil.
Kieran Chandler: Y si tienes una versión con gran granularidad, va a ralentizar a todos, incluyendo cosas que deberían ser súper rápidas, como simplemente escanear un código de barras y hacer beep. He escaneado, puedes proceder al siguiente artículo. ¿Qué tan obvios son algunos de estos desafíos? Tienes que simpatizar con un profesional de supply chain. Quiero decir, hay muchísimo sucediendo, y con tanto tiempo usando este software, hay un montón de cosas ocurriendo tras bambalinas. ¿Qué tan obvio es que algunos de estos desafíos existen?
Joannes Vermorel: No es obvio porque, usualmente, no se trata de un bug evidente que haga que tu sistema se caiga. Es más bien como una muerte por mil cortes. Permíteme ilustrar: tienes este sistema que se supone es en tiempo real. Cuando algo se escanea en una cinta transportadora de alta velocidad, deberías poder hacer beep a tres artículos por segundo, o algo así. Deberías ser realmente rápido y tener tiempos de respuesta en milisegundos.
Ahora, ¿qué sucede si, de vez en cuando, tienes un cálculo que simplemente tarda unos pocos segundos en lugar de milisegundos? Si solo tienes una operación, de vez en cuando, que demora unos segundos, y tu sistema en tiempo real está bien diseñado, probablemente la mayoría de las otras operaciones se mantendrán súper rápidas, así que no afecta tanto. Excepto, si no tienes suerte, y al mismo tiempo tienes como diez operaciones diferentes que toman varios segundos en computarse. Eso simplemente absorbe, en ese momento específico, todos los recursos de cómputo.
Entonces, lo que sucederá es que el sistema que se suponía debía poder escanear y darte retroalimentación en milisegundos, de repente tarda un segundo. No es lo ideal, pero puedes vivir con ello. Sin embargo, de vez en cuando ocurre que esperabas algo ultrarrápido, pero de repente hay dos o tres segundos de retraso. Por cierto, puedes ver que a veces, incluso en supermercados locales, tienes un punto de venta y el beeping de los artículos es muy fluido, pero en algún momento, simplemente beepan algo y pasan tres segundos, y luego beep.
Aquí, tienes un sistema en tiempo real que se vio congestionado por una operación que no es en tiempo real. No sé qué fue, tal vez una actualización de Windows o algún tipo de cosa extraña que sucede y ralentiza la máquina. Pero en un sistema en tiempo real, no se te permite hacer nada inteligente o complejo porque eso degradaría las operaciones súper rápidas que deseas realizar.
Cuando digo muerte por mil cortes, es porque la primera vez que haces algo no en tiempo real en un sistema en tiempo real, probablemente no suceda nada malo. Es raro, así que, en cierto modo, estás bien. Pero el problema es que acumulas cada vez más cosas no en tiempo real, y de repente esos problemas que eran muy infrecuentes comienzan a ser cada vez más frecuentes, hasta que se vuelven súper frecuentes. Entonces, la gente se vuelve loca, diciendo, “¿Por qué esta cinta transportadora no funciona más rápido? Podría hacerlo.”
La respuesta es porque hay una máquina que se supone que debe escanear el código de barras, y tenemos que esperar a que el sistema responda. He visto situaciones en las que el sistema tardaba medio minuto en responder después de escanear un código de barras. Se trataba de imprimir algo para colocar en la caja, pero la cinta transportadora se veía limitada por la velocidad a la que el sistema podía entregar la orden a la impresora para imprimir algo en la caja. Tenían gente esperando a que la impresora imprimiera.
Tienes muchas opciones de diseño que deben acertar en las elecciones fundamentales, de maneras que están profundamente alineadas con los problemas que intentas resolver.
Kieran Chandler: ¿Cuáles son los supuestos básicos clave que se están haciendo en el software de supply chain, y cuáles has observado que realmente no están funcionando?
Joannes Vermorel: Hay muchas formas de abordar esto. Primero, considera la escala de tiempo en la que deseas operar. Tenemos cosas que deben funcionar con tiempos de respuesta sub-milisegundo, que es lo que necesitas literalmente para mover una cinta transportadora, hasta decisiones en las que necesitas pensar una década en el futuro, como la ubicación de las fábricas. Cada vez que añades un orden de magnitud, cambias el software fundamentalmente.
Kieran Chandler: ¿Puedes dar algunos ejemplos de diferentes escalas de tiempo y los correspondientes tipos de software?
Joannes Vermorel: Claro. El software de sub-milisegundo es un tipo; de 1 a 10 milisegundos, es otro tipo de software; de 10 a 100 milisegundos, es otro, que es típicamente software ERP con tiempos de respuesta de 10 a 100 milisegundos. De 100 milisegundos a 1 segundo, obtienes el tipo de cosas que puedes encontrar en una aplicación web. Luego, si empiezas a pensar de 1 a 10 minutos en el futuro, ya no estás en tiempo real, pero puedes comenzar a hacer cálculos sofisticados. Por ejemplo, una aplicación de navegación como Waze necesita proporcionar una ruta en medio minuto, pero no necesita ser en tiempo real.
Si estás optimizando una ruta para entregas de camiones, normalmente puedes tardar varios minutos en obtener los resultados, ya que no necesita ser en tiempo real. En Lokad, normalmente nos enfocamos en plazos de 1 día a 1 año. Este es el punto óptimo para nosotros, y significa que prácticamente podemos ignorar todo lo anterior. Si vamos más allá de un año, entramos en el ámbito del diseño de supply chain, que es más centrado en mapas y cambia el problema.
Kieran Chandler: Hablemos un poco más sobre la implementación del software. ¿Cuáles son las diferencias clave entre el software single tenant y multi-tenant?
Joannes Vermorel: La diferencia entre single tenant y multi-tenant es cuántos clientes atiendes con la misma pieza de software. Si eres multi-tenant, como Lokad, es el mismo software sirviendo a todos nuestros clientes. Solo tenemos una versión desplegada en línea en un momento dado, y actualizamos este software semanalmente. La otra alternativa, que era más común antes del advenimiento del SaaS, es single tenant. Este enfoque implica dar a cada cliente su propia copia del software, lo que a menudo resulta en personalización para grandes clientes.
Producir el software significa que, de repente, terminas con muchas variantes de tu software que se ejecutan al mismo tiempo, lo cual es un gran problema operativo porque significa que, si hay un error en una versión, tienes que arreglar esa versión, pero debes asegurarte de que el error también se solucione en todas las demás versiones. Por cierto, este es un problema en el que, para las empresas de software, se presentan como anti-economías de escala. Cuanto más grande eres, más problemas tienes con la gestión de versiones. Por cierto, este problema está afectando muy severamente a Oracle, por ejemplo, con la base de datos de Oracle. Tienen muchas versiones altamente personalizadas que están optimizadas para el rendimiento. No tengo información interna secreta, pero a partir de la información pública, puedes ver que, literalmente, en varias divisiones de ingeniería de Oracle, están lidiando con el hecho de que hay muchas variantes del software. Obviamente, Oracle tiene una gran capacidad de ingeniería, pero, aun así, sigue siendo un gran desafío. Así, single tenant te ofrece la opción de personalización por cliente, pero luego tienes que lidiar con la sobrecarga por cliente. Multi-tenant te ofrece el beneficio de tener una base de código para todos, sin personalización, pero a cambio, puedes evolucionar mucho más rápido y tener muchos menos problemas de seguridad.
Kieran Chandler: Cuando dices que el mercado se está moviendo hacia ese tipo de modelo SaaS, ¿por qué este modelo es mucho mejor? ¿Ofrece un mayor grado de flexibilidad para la empresa?
Joannes Vermorel: Sí, en la última década, prácticamente todos los proveedores de software serios se han movido hacia la multi-tenancy, incluso las aplicaciones de escritorio tradicionales clásicas. Porque, obviamente, si eres una aplicación web como Lokad, ser multi-tenant es bastante sencillo. Vuelves a desplegar las cosas en tus propios sistemas y, listo. Obviamente, cuando tienes software que opera en las máquinas cliente, como, por ejemplo, tu navegador —ya sea Internet Explorer o Google Chrome— es más complicado porque no tienes control sobre las máquinas cliente. Pero, ¿adivina qué han hecho los proveedores de software? Han cambiado a la estrategia evergreen. Por ejemplo, Google Chrome ya no te pregunta sobre actualizar el navegador. Cuando Google decide que tu versión de Chrome está desactualizada y necesita ser reemplazada, Google actualiza tu navegador a distancia. Obviamente, la próxima vez que te conectes a internet y demás, no pueden actualizar mágicamente tu software si no tienes conectividad. Pero, asumiendo que tienes conectividad a internet y no has realizado ninguna maniobra específica en tu máquina para evitar la actualización, la actualización ocurrirá, básicamente, sin tu intervención. Y cuando miras lo que Microsoft está haciendo con Office 365, es lo mismo. En el pasado, tenías una serie de versiones de Microsoft Office cuando pasabas de una versión de Excel a la siguiente. Hoy en día, es on-demand, y Microsoft se encarga de la actualización. Tienes una suscripción, el software está instalado en tu máquina, pero puede actualizarse solo a la siguiente versión. Y si simplemente lo dejas, a menos que desactives tus opciones de actualización, Microsoft está actualizando todas las aplicaciones de escritorio precisamente para mitigar el problema de tener muchas versiones del mismo software.
Kieran Chandler: Hablemos un poco sobre Lokad entonces. Dijiste que había ciertos supuestos básicos que deben hacerse en el diseño del software y que pueden impactar realmente las operaciones futuras. Entonces, ¿cuáles fueron los supuestos básicos que hiciste aquí en Lokad?
Joannes Vermorel: Hay toneladas de ellos, pero antes de entrar en los supuestos básicos, me gustaría hacer una nota. Si te encuentras con un proveedor de software que
Kieran Chandler: …Que te dice “todo mi software, ya sabes. Somos capaces de todo lo que no hicimos”, ya sabes, esos supuestos de software. Si te dan solamente, ¿puedo sugerir, ya sabes, cuando te reúnas con un proveedor de software para tu supply chain, pregúntales cuáles son los supuestos básicos? Y si te dicen algo vago como, “estamos diseñados para la seguridad”, genial. “Estamos diseñados para la velocidad”, sí, yo también. “Estamos diseñados para la eficiencia de costos”, sí. Ya sabes, estas son cosas súper vagas, absolutamente positivas. Pero cuando hablamos de diseño, la perspectiva del diseño es un compromiso. Es algo que tiene aspectos positivos y negativos. Entonces, si puedes discutir con el proveedor de software y todo lo que te pueden dar son los aspectos positivos, probablemente es que ni siquiera entienden la naturaleza del diseño de software en primer lugar. Entonces, Joannes, ¿cuáles son los supuestos básicos de diseño que incorporaste en Lokad?
Joannes Vermorel: El primero fue un modo de procesamiento por lotes. ¿Qué significa eso? Significa que lo que queremos es ser capaces de procesar toneladas de big data y realizar cálculos muy inteligentes. Obviamente, porque queremos, preferimos ser muy inteligentes en lugar de ser muy, muy rápidos, lo que significa que, para nosotros, tener cálculos que típicamente se ejecutan en minutos, pero el hecho de que puedan ejecutarse en segundos es una especie de bonificación. Pero si no podemos, no es tan grave. Preferimos tener mejores números incluso si toma un poco de tiempo. Por cierto, no es porque haya partes nuestras que dependan de ese “tiempo de rueda”, es solo una presentación de los resultados. Así, puede que necesites, digamos, media hora para hacer un cálculo masivo, pero cuando quieras acceder a esos resultados, entonces necesita ser en tiempo real, aunque esté precomputado. Así que ves que ese fue un supuesto básico de diseño. No en tiempo real, es por lotes. Y la razón es que queremos ser muy expresivos y muy poderosos y, por lo tanto, ser tan inteligentes como podamos para, diría, un análisis net mundial. Ese es un supuesto básico. Otro fue que queríamos tener multi-tenancy. Obviamente, hoy en día, la mayoría de las personas hacen eso, pero todavía hay empresas que, especialmente en el sector empresarial, van rezagadas. Y diría que multi-tenancy se hizo con todas sus aristas.
Kieran Chandler: ¿Puedes explicar la diferencia entre scalable y scale out?
Joannes Vermorel: Las capacidades ofrecidas por la computación en la nube significan que queremos tener capacidades de scale out en lugar de scale up. La pregunta es: si quieres procesar terabytes de datos, ¿puedes hacerlo acumulando toneladas de pequeñas máquinas o necesitas un superordenador para hacerlo?
Kieran Chandler: Entonces, ¿cuál es nuestra conclusión principal hoy?
Joannes Vermorel: Nuestra conclusión principal es que, en cuanto a los datos que tenemos y a la hora de tomar decisiones sobre software, esto puede encasillar en gran medida lo que haces en el futuro. Por lo tanto, necesitas comprender completamente las elecciones que estás haciendo.
Kieran Chandler: ¿Puedes elaborar sobre eso?
Joannes Vermorel: Mi sugerencia sería que los profesionales de supply chain sean más conscientes de los supuestos básicos de diseño que caracterizan su propio paisaje aplicativo. Tienen muchas apps, y ¿pueden darme media docena de supuestos críticos de código que expliquen los entresijos del producto? Puede sonar súper técnico, pero si no entiendes esos supuestos básicos de diseño, vas a sufrir mucho cuando te des cuenta de que estás intentando hacer algo para lo que, por diseño, este no va a ser un buen producto. Con frecuencia, he visto muchas empresas donde, literalmente, sus problemas surgen de un desajuste entre el diseño del software y lo que intentan hacer con él.
Kieran Chandler: ¿Puedes dar un ejemplo?
Joannes Vermorel: Los proveedores tratan de mostrarse muy confiados, ya sabes, como proveedor, intentas vender tu software. Quieres actuar con seguridad y decirle al cliente que tu software de supply chain va a ser excelente en todas las situaciones, y que lo tenemos cubierto. Pero la realidad es que, si un cliente va a usar tu software para algo que está fuera de tus capacidades de diseño, no puedes simplemente parchearlo. No puedes simplemente añadir una función. Los ingenieros de software en el back-end te van a decir, “Jefe, lo sentimos, no podemos hacerlo. Va a ser un infierno.”
Kieran Chandler: Muy bien, vamos a concluir. Gracias, Joannes. Eso es todo por esta semana. Muchas gracias por acompañarnos, y nos veremos de nuevo la próxima vez. Adiós por ahora.
