A pesar de las ventajas de la simplicidad, lamentablemente la complejidad vende más (2022)
(eugeneyan.com)- Detrás de que los métodos simples sean peor valorados en la revisión de artículos o en evaluaciones de ascenso existe un sesgo hacia la complejidad, porque los resultados complejos parecen contener más esfuerzo, pericia e innovación
- Los sistemas con muchas opciones y componentes parecen más flexibles, pero en la operación real pueden volverse más difíciles de explicar, probar y depurar, y aumentar los errores y la ineficiencia
- Las ideas y sistemas simples son más fáciles de entender, usar, recibir retroalimentación y escalar; al momento de su adquisición en 2012, Instagram atendía a decenas de millones de usuarios con un equipo de 13 personas mientras mantenía tecnologías probadas como PostgreSQL y Redis
- Incluso en machine learning, las técnicas complejas no siempre son superiores: en 45 conjuntos de datos tabulares de tamaño mediano, los modelos basados en árboles superaron a las redes neuronales profundas, y en recomendación y búsqueda hay casos donde el producto punto (dot product) supera al neural collaborative filtering
- Recompensar la complejidad en sí misma fomenta la complejidad innecesaria y la tendencia de not invented here, por lo que cuanto más complejo sea el problema, primero hay que evaluar si es posible una solución simple y si el costo de la complejidad está justificado
Por qué la complejidad parece más atractiva
- La complejidad se interpreta fácilmente como una señal de esfuerzo
- Los artículos con ideas difíciles y muchos detalles técnicos parecen haber requerido mucho tiempo y esfuerzo
- Los sistemas con muchos componentes y funciones tienden a evaluarse como resultados más trabajados que los sistemas más pequeños
- La impresión de que algo es difícil de construir termina funcionando como señal de valor y calidad
- También se interpreta como señal de pericia
- Un sistema con muchas partes móviles da la impresión de que quien lo diseñó tiene la capacidad de entender e integrar cada parte
- Los artículos llenos de terminología especializada y demostraciones son difíciles de abordar, pero parecen mostrar mayor dominio del tema
- La práctica de preguntar en entrevistas sobre algoritmos y estructuras de datos que casi no se usan en el trabajo real también se relaciona con este tipo de señal
- También existe la percepción de que es una señal de innovación
- Un artículo que crea una arquitectura de modelo completamente nueva suele evaluarse como más novedoso que uno que modifica una red existente
- Un sistema con muchos componentes hechos desde cero parece más original que uno que reutiliza piezas existentes
- La valoración de “solo cambia una cosa y todo lo demás es igual a trabajos previos” puede restarle valor a una idea simple
- Cuantas más funciones tiene algo, más se genera la ilusión de que es más integral
- Un sistema que soporta tanto almacenamiento SQL como NoSQL, o que permite tanto pipelines batch como streaming, parece capaz de cubrir todos los casos
- Se cree que mientras más bloques tipo Lego haya, mejor se podrá responder a los cambios
- Este tipo de juicio lleva a un complexity bias que favorece en exceso lo complejo por encima de las ideas y sistemas simples
Dónde la simplicidad sí aporta ventajas reales
- Las ideas y funciones simples son más fáciles de entender y usar
- Aumentan las probabilidades de adopción y el impacto real
- También son más fáciles de comunicar y de recibir retroalimentación
- Los sistemas complejos son difíciles de explicar y administrar, por lo que a los usuarios les cuesta entender qué deben hacer y cómo hacerlo
- Si hay demasiadas cosas que ajustar, aumentan los errores; si hay demasiados pasos, aparece la ineficiencia
- Los sistemas simples son más fáciles de construir y escalar
- Con menos componentes, la implementación se vuelve más sencilla
- Si se usan tecnologías estándar ya disponibles, es más fácil encontrar personas que puedan implementarlas y mantenerlas
- Al reducirse el código y las interacciones internas, también baja la carga de comprensión y pruebas
- Los sistemas innecesariamente complejos terminan consumiendo más tiempo y recursos para construirse, lo que genera desperdicio
- El caso de Instagram muestra las ventajas de elegir tecnología simple
- En el momento de su adquisición en 2012, Instagram atendía a decenas de millones de usuarios con un equipo de 13 personas
- En vez de adoptar tecnologías nuevas de moda, mantuvo tecnologías probadas para reducir la carga operativa por ingeniero
- Mientras otras startups adoptaban almacenes de datos NoSQL de moda y enfrentaban dificultades, Instagram usaba PostgreSQL y Redis, que son fáciles de entender
Costos operativos y mantenibilidad
- Desplegar un sistema no es el final, sino el punto de partida
- La mayor parte del esfuerzo ocurre después de ponerlo en producción
- Es muy probable que la operación quede a cargo de otras personas y no del equipo que lo creó originalmente
- Un sistema simple puede reducir los costos de mantenimiento y alargar su vida útil
- Cuantas menos piezas móviles haya, más confiable y más fácil de reparar será
- Se reducen las partes que pueden fallar
- Al haber menos interacciones internas, es más fácil actualizar o reemplazar componentes individuales
- Un sistema complejo aumenta los costos de mantenimiento porque un equipo limitado debe entender más componentes
- Si hay muchas partes interdependientes, resolver problemas también se vuelve más difícil
- Thomas Paine dijo en Common Sense: “Cuanto más simple es algo, menos probable es que se descomponga, y si se descompone, más fácil es repararlo”
Casos donde las técnicas simples no se quedan atrás ni siquiera en machine learning
- Las técnicas más sofisticadas no siempre ofrecen mejor desempeño
- Tree-based models > deep neural networks: en 45 conjuntos de datos tabulares de tamaño mediano, los modelos basados en árboles fueron mejores que las redes neuronales profundas
- Greedy algorithms > graph neural networks: en problemas combinatorios sobre grafos, los algoritmos greedy fueron mejores que las graph neural networks
- Simple averaging ≥ complex optimizers: en problemas de aprendizaje multitarea, el promedio simple fue igual o mejor que optimizadores complejos
- Simple methods > complex methods: en la precisión predictiva a lo largo de 32 artículos, los métodos simples fueron mejores que los complejos
- Dot product > neural collaborative filtering: en recomendación de ítems y búsqueda, el producto punto fue mejor que neural collaborative filtering
Problemas que surgen cuando se recompensa la complejidad
- Si se recompensa la complejidad, se incentiva a las personas a crear cosas innecesariamente complejas
- Los métodos o sistemas simples pueden evaluarse como menos valiosos solo porque parecen fáciles
- Si se complejiza un sistema para obtener recompensas, la solución más simple deja de ser una opción claramente preferible
- La complejidad genera más complejidad, y al final puede llevar el trabajo a un nivel inmanejable
- También se refuerza la tendencia de not invented here
- Aunque reutilizar componentes existentes puede ahorrar tiempo y esfuerzo, surge la tendencia de querer construir todo desde cero
- Eso puede desperdiciar tiempo y recursos, y llevar a peores resultados
- En los procesos de ascenso y en la revisión de artículos de machine learning, la complejidad también puede enfatizarse en exceso
- Bryan Liles señala que una solución simple es más fácil de implementar y escalar que una compleja, pero que muchas veces los ascensos se otorgan a quien construyó la solución compleja
- Micah Goldblum dice que en revisiones de ML es común criticar que un método es demasiado simple o que está armado con componentes existentes, cuando la simplicidad no es una debilidad sino una fortaleza
- Innovaciones como Kalman Filters, PageRank, SVM, LSTM, Word2Vec y Dropout también fueron rechazadas alguna vez
Una mejor manera de abordar la complejidad
- El objetivo es resolver problemas complejos con la solución más simple posible
- Hay que concentrarse en la complejidad del problema, no en la complejidad de la solución
- Una solución simple demuestra comprensión profunda del problema y la capacidad de evitar soluciones más enredadas y costosas
- Esto se conecta con la frase de Albert Einstein: “Todo debe hacerse tan simple como sea posible, pero no más simple”
- En lugar de una solución compleja que intente cubrirlo todo, puede considerarse varias soluciones enfocadas
- Una solución universal (one-size-fits-all) puede ser menos flexible y menos reutilizable de lo esperado
- Si se intenta soportar al mismo tiempo múltiples casos de uso y partes interesadas, el sistema queda más fuertemente acoplado y requiere más coordinación para planificación y migración
- Un sistema de propósito único es más fácil de operar y también más fácil de descartar cuando haga falta
- Para reducir el sesgo hacia la complejidad, se puede aplicar la navaja de Occam
- Es el principio de que la solución o explicación más simple suele ser la correcta
- No hay que descartar demasiado rápido las ideas simples ni agregar complejidad innecesaria para justificar su valor
- Hay que considerar el costo de la complejidad y preguntar: “¿realmente vale la pena?”
El sesgo opuesto: reutilizar complejidad conocida
- Del lado opuesto de “not invented here” también existe un sesgo de preferir automáticamente componentes existentes
- Porque ya se conocen, parecen más fáciles desde la experiencia personal y reducen el tiempo y esfuerzo propios
- Pero si el componente existente es en sí muy complejo, puede desperdiciar más tiempo y recursos y producir peores resultados que crear algo nuevo más simple
- Cuando no hay una opción simple, puede ser necesario construir algo nuevo
- A veces lo nuevo tampoco termina siendo realmente simple y solo se convierte en otra cosa tan compleja como la existente
- Algunos problemas son intrínsecamente complejos y tienen una essential complexity que no puede eliminarse
- ORM se presenta como un mal ejemplo
- Los ORM se vuelven a crear una y otra vez y suelen empezar siendo simples, pero al final su complejidad explota
- El object/relational impedance mismatch es bien conocido, y la idea misma de ORM es intrínsecamente compleja
- Si algo parece haber mantenido la simplicidad, probablemente no sea un ORM sino un query builder o un data mapper
- La API de caché PSR es un caso de complejidad eliminable
- Después de la API de caché PSR-6, apareció la API de caché más simple PSR-16
- PSR-16 reduce la complejidad y la cantidad de conceptos, haciendo la API más pequeña y menos opinionated
- El hecho de que se pueda crear un adaptador de PSR-6 para implementar PSR-16 y un adaptador en la dirección opuesta muestra que la complejidad eliminada en PSR-16 no era esencial
- Algunas librerías y frameworks pueden crecer más allá de la complejidad esencial en nombre de la experiencia del desarrollador
- La simplicidad real tiene rasgos que se pueden medir con métricas como líneas de código, cantidad de métodos públicos o nivel de acoplamiento
- Hay casos en los que una librería crece 10 veces respecto a su tamaño original en pocos años y además introduce grandes breaking changes cada 6 a 12 meses
- Considerar que una librería sin crecimiento está “muerta” y querer migrar a un paquete más “activo” también puede ser un síntoma del sesgo hacia la complejidad
- Para evitar la complejidad que se expande, a veces sí hace falta optar por construir algo nuevo
- Si se pueden fijar los requisitos y evitar que el alcance siga expandiéndose, una nueva implementación puede ser la opción más simple
- Hay que tener cuidado de no reforzar ninguno de los dos sesgos
1 comentarios
Opiniones de Hacker News
Trabajé en una empresa de FAANG en una época en la que resolver problemas complejos se usaba como criterio de ascenso: cuanto más complejo era el problema que resolvías, más subían tu nivel, compensación y estatus.
Naturalmente, la gente empezó a buscar problemas complejos que pudieran resolver, y como otras empresas copiaron las ideas de esa compañía, parece que incluso empresas pequeñas que no necesitaban soluciones complejas terminaron con stacks tecnológicos similares.
Pensé algo parecido al ver las UI de los autos actuales, especialmente las UI complejas y difíciles de manejar de los eléctricos, al punto de que eso me impide comprar un auto que las requiere.
Mi conclusión es que los consumidores sofisticados y los consumidores aspiracionales son muy distintos, y que estos últimos son muchos más.
Por eso, tiene sentido económico sacrificar a los consumidores sofisticados para adaptarse a los aspiracionales.
Los consumidores aspiracionales toleran fallas y trucos porque los aceptan como símbolos de logro en el consumo.
Dicho de forma brusca: están tan felices de manejar un auto “de lujo” que no ven la basura que viene incluida, mientras que quienes llevamos décadas comprando autos de lujo solo queremos que la palanca de cambios sea fácil de entender.
Los objetivos táctiles se volvieron demasiado pequeños sin razón, y parece que los desarrolladores diseñaron y probaron la UI en pantallas sobre escritorios fijos o en autos inmóviles.
Dentro de un auto en movimiento, todo se arruina.
Los modelos más nuevos sin palanca de cambios, direccionales, limpiaparabrisas ni palanca de luces son un caos.
Sentado al volante, tienes que acertarle a objetivos pequeños en una pantalla donde ni siquiera tienes dónde apoyar la mano; por el control indirecto, la confusión, la imprecisión y la distracción, todo eso hace que la gente maneje peor.
Automatiza cosas molestas como bloquear y desbloquear, cerrar ventanas, precalentar o preenfriar, configurar automáticamente la navegación hacia el trabajo por la mañana y hacia casa por la tarde, y ajustar el asiento y la configuración según qué llave de teléfono se usó.
Gracias a la conectividad gratuita, la navegación también funciona bien; todos los GPS integrados en autos que había probado antes eran inútiles.
La pantalla de selección y reproducción de música también es buena, y los comandos de voz funcionan bastante bien para elegir música.
No es perfecto, pero me parece mejor que todos los autos de combustión interna que he manejado hasta ahora.
El proceso de salir al trabajo por la mañana se reduce a dos pasos: abrir la puerta y poner el modo de manejo.
En invierno, con un auto de combustión interna, eran más de 10 pasos: buscar la llave, abrir el auto, abrir la puerta, ajustar el asiento después de que manejó mi esposa, botón de encendido, desempañar el parabrisas, activar el desempañador trasero, raspar el hielo del parabrisas, elegir el trabajo en el GPS, quitar el freno de mano, embrague y meter el cambio.
Gente que no tiene uno se la pasa lamentándose en línea por la pantalla táctil, pero los dueños de Tesla siguen con la marca porque, con pantalla táctil o sin ella, es mejor que otros autos.
Technology Connections dijo en un video reciente que, para cambiar los limpiaparabrisas, tuvo que sostener durante 4 segundos una fea palanca estilo años 90, y que tuvo que leer el manual para descubrirlo.
En autos hechos con piezas añadidas por separado, este tipo de comportamiento basura es muy común.
En cambio, mi auto me envía al teléfono alertas de video de vigilancia en tiempo real, maneja por mí en el trayecto al trabajo y, para cambiar de marcha, normalmente basta con ponerse el cinturón y pisar el freno para que el auto elija la dirección por sí solo.
Las funciones importantes están disponibles de forma contextual desde el volante, no mediante 50 botones.
Es simple y potente; el problema está en la pésima ejecución de los autos de lujo mencionados antes.
A veces veo a un YouTuber llamado Theo Browne, que principalmente es desarrollador frontend.
Cuando lo veo explicar una solución, siento como si me hubieran pegado en la cabeza con un bate de béisbol, y la cantidad de elementos que entran en sus demos es para llorar.
También me sorprende la cantidad de términos crípticos relacionados con React que menciona en un solo video.
No quiero señalar a una persona en particular para criticarla, pero me preocupa que esa complejidad sea lo que mantenga su popularidad.
En cambio, Pieter Levels mete PHP puro directo a producción sin hablar de Suspense, renderizado del lado del servidor ni Hydration.
Ambos terminan llegando al mismo objetivo, pero sospecho que Pieter Levels gana muchísimo más dinero, y la brecha de complejidad es enorme.
De hecho, creo que algo como Nomad List es mucho más rico en funciones que lo que veo de Theo.
Después vi que otra persona lo reconoció y tuvieron una discusión amistosa a los gritos sobre un tema del que Theo había hablado con fuerza en su canal.
Su personalidad parecía perfectamente adecuada para maximizar la participación mediática mediante complejidad innecesaria.
Cuanto más complejo es algo, más temas hay para debatir, y puede hacerte parecer más inteligente ante quienes no están familiarizados con opciones difíciles de entender.
La cantidad de librerías y código usados en ejemplos de juguete es mucho mayor que lo que veo en producción, y eso que he visto sistemas bastante monstruosos.
No sé cuánto tiempo va a durar esto.
Viene incluida un montón de cosas misceláneas que no vas a usar, y termina estorbando justo las partes que sí vas a usar.
Si surge un problema, ahora tienes que entender no solo el lenguaje de programación y tu propio código, sino también el código dentro del framework por el camino que estás recorriendo.
Ese camino puede bajar fácilmente hasta 10 o 20 funciones de profundidad, y es extremadamente raro que esté documentado con suficiente detalle qué ocurre en distintos casos límite.
La cantidad de herramientas que se usan para construir cosas relativamente simples es enorme, y siento que en DevOps pasa algo parecido.
Creo que este problema lo crearon los “desarrolladores frontend” de empresas.
Parece que una especie de complejo de inferioridad frente a la “ingeniería de verdad” que hacen los desarrolladores full stack o backend hizo que el frontend también quisiera crear problemas de “ingeniería de verdad”.
Tras décadas desarrollando sistemas legacy, a veces con diseños de nuestra empresa y a veces en trabajos por contrato para clientes, vi muchas situaciones que me hicieron creer que ciertos clientes prefieren software complejo y lleno de bugs.
La razón es que pueden esconderse detrás de eso.
Cosas como “no terminé a tiempo porque el software tenía bugs”, “no pude hacer X porque el software no soporta Y”, o “el perro se comió mi tarea”.
En muchos casos se podría haber diseñado una solución simple, fácil y con muchos menos bugs, pero entonces a los usuarios les resultaría más difícil ocultar que cierto fracaso quizá no fue un problema del software, sino de su propia incompetencia.
Por eso, especialmente en empresas con mucha presión desde arriba, los gerentes en realidad prefieren trabajar con software que no entienden del todo y que se sabe que tiene bugs y problemas.
A los 27 años, cuando cambié de mi primer trabajo después de 5 años, reemplacé un programa GUI supercomplejo por una pequeña GUI que envolvía dos programas CLI.
Funcionaba siempre incluso con entradas incorrectas, y cuando fallaba en raras ocasiones daba mensajes de error útiles.
Las tres mujeres que lo usaban realmente me odiaban.
Recién más o menos un año después de irme de la empresa entendí por qué, y en ese momento yo no era muy listo.
Con el tiempo llegué a pensar que la gente quiere cosas como Microsoft Teams porque, cuando lo necesita, puede usarlas para cubrirse las espaldas.
En interfaces físicas, en nuestro grupo a esto lo llamamos el problema del microondas.
Nadie usa los 20 botones adicionales de un microondas, y la mayoría usa solo uno o dos, pero nadie compra un microondas con pocos botones.
Llevo 10 años encantado con mi Samsung ME82V, y con dos perillas basta.
Así que comer un snack a escondidas a las 2 de la mañana implica vigilar el microondas como en 1999.
Lo único que quieres es un dial de velocidad, un interruptor de pulso y un interruptor de encendido, y todos quieren eso, pero por alguna razón en cada generación les agregan un montón de funciones que nadie usa.
No necesariamente uso siempre los mismos dos botones, así que me gusta tener la opción de poder usar otros.
Además, cuando hay muchos botones, con bastante frecuencia también vienen mejores especificaciones.
Tenían menos controles y menos funciones, pero la experiencia de usuario era excelente.
Recuerdo lo limpio que era el iPod comparado con productos competidores excesivamente cargados de funciones y complejos.
Este tipo de lamento molesta porque está lleno de máximas obvias.
Es fácil parecer inteligente citando a Einstein y Dijkstra, y también es fácil generalizar soluciones complejas y señalar con el dedo aprovechando el beneficio de la retrospectiva y el desconocimiento de los requisitos reales.
“Tan simple como sea posible, pero no más simple” siempre es cierto.
Si la solución era desordenada, debió haberse hecho más simple; si una solución primitiva causó problemas, entonces no debió haberse hecho tan simple.
Es como decir: ¿por qué no se les ocurrió simplemente hacerla perfecta?
En la realidad, cuando una solución tiene múltiples compromisos, incluso ponerse de acuerdo sobre qué es simple es muy difícil.
Mantener una sola base de datos compleja puede ser más fácil que tener tres bases de datos “simples”, triplicar el trabajo de administración y terminar implementando sincronización o transacciones distribuidas.
Lo que es fácil de implementar ahora puede crear problemas complejos más adelante, y una solución prefabricada que no resuelve el problema por completo puede generar soluciones alternativas complejas para los casos que no soporta, para luego añadir además la complejidad de migrar finalmente a algo adecuado.
El consejo de “simplemente hazlo simple” muchas veces ignora que esa solución no es una panacea y que en la realidad rara vez hay opciones claras entre complejidad y simplicidad.
Los proyectos tienen restricciones como sistemas existentes desordenados, requisitos legales incoherentes y necesidades de negocio cambiantes, y también pueden priorizar la velocidad de lanzamiento o las capacidades que se pueden contratar.
La economía también es implacable: aunque la exportación del informe anual parezca una máquina de Rube Goldberg, se usa solo una vez al año y quizá reescribirla no recupere el costo ni en 50 años.
Las discusiones sobre complejidad casi nunca reconocen que los proyectos y los requisitos crecen.
Algo que hoy es perfectamente simple puede volverse complejo más adelante de una manera totalmente razonable, no por incompetencia ni mala fe.
Al principio, guardar datos en un archivo de texto plano es hermosamente simple, pero más adelante puede convertirse en una pésima base de datos NIH.
Dicho eso, usar una base de datos desde el inicio para tres líneas de datos también es sobrediseño.
Refactorizar tiene un costo, así que usar siempre la solución ideal tampoco es algo tan simple.
Muchas menos cosas de las que creemos son realmente obvias.
Interpretar “tan simple como sea posible, pero no más simple” como una exigencia de perfección no se sigue lógicamente.
En la práctica sabemos que la iteración vence a la planificación.
Si es difícil ponerse de acuerdo sobre qué es simple, no pidas permiso: pide perdón.
Es una regla que funciona en esta industria, y quizá en muchas otras.
Definitivamente hay un tipo particular de complejidad accidental que se ve en soñadores y desarrolladores frontend.
La complejidad es compleja.
Los sistemas más complejos también tienen el efecto secundario de generar muchos materiales periféricos, como tutoriales y videos.
Además, para quienes los aprenden, los convierten en personas con habilidades y responsabilidades necesarias dentro de una empresa, lo que les da más estabilidad laboral que algo que simplemente funciona bien y no requiere a ese tipo de persona.
En IT hay demasiados empleos que no existirían si el software estuviera hecho para ser simple y simplemente funcionar.
En los casos simples, “simplemente funciona”, pero está bien siempre que no intentes mirar por dentro ni hacer nada no trivial.
Quizá la analogía sea bastante acertada.
Si hablamos de revisión de papers, como revisor, lo que busco en un paper no es simplicidad ni complejidad, y tampoco “novedad”.
Lo que busco es un análisis empírico exhaustivo y que provoque reflexión sobre el problema.
Entre los envíos hay muchos que 1) proponen un sistema tipo Frankenstein cosido con una docena de ideas existentes y logran obtener “números en negrita” usando al máximo los juguetes más recientes que tienen a mano, sin analizar en profundidad los modos de falla de cada parte; o 2) modifican ligeramente un método existente y por casualidad mejora el rendimiento, pero sin una justificación empírica o teórica adecuada de por qué ayuda.
El segundo tipo puede tener un valor muy pequeño para la comunidad o los lectores, pero en su mayoría lo considero inútil.
Lo que sí es valioso para el lector es cuando un estudiante de doctorado observa un problema durante mucho tiempo, logra conectar su intuición con una confirmación cuantitativa y verificable, y obtiene una observación reproducible con poder predictivo.
Por ejemplo: “verificamos experimentalmente en todos los casos que X afecta a Y mediante el mecanismo Z descrito en este paper, y por eso mejoramos la métrica A en B%, lo cual es consistente con Z”.
Independientemente de la complejidad, algo del estilo “hicimos X y A subió B%” no alcanza.
Lamentablemente, no todos los revisores están de acuerdo.
Mi profesor de historia de la secundaria nos encargó escribir un ensayo sobre los acontecimientos que llevaron a la Segunda Guerra Mundial.
La primera pregunta fue qué extensión debía tener, y el profesor respondió que si alguien podía tratar ese tema complejo en una hoja A4, le daría la máxima calificación, aunque sinceramente dudaba que se pudiera cubrir en un texto tan corto.
A todos nos impactó esa lógica.
Nadie había escuchado nunca a un profesor decir algo así, y eso muestra que desde niños nos enseñan que más siempre es mejor.
Una explicación siempre puede hacerse larga o corta eligiendo el nivel de abstracción, y la gente normalmente elige ese nivel según el contexto y las convenciones sociales.
Por ejemplo, “cómo una pulsación de tecla termina convirtiéndose en una letra en pantalla” puede explicarse en una sola oración, o en varios libros largos si se entra en firmware, stack de software, electrónica, ciencia de materiales y procesos de fabricación.
También se puede decir que la Segunda Guerra Mundial empezó cuando Hitler invadió Poland y France, o remontarse al Tratado de Versailles, o incluso hablar de la evolución de la vida en la Tierra.
Lo último es pedante, pero técnicamente sí fue un acontecimiento que llevó a la Segunda Guerra Mundial.
Recomiendo mucho la charla Simple Made Easy de Rich Hickey
La complejidad no vende nada bien, pero lo fácil sí vende
Si una empresa puede contratar a mucha gente que sepa usar “foo” y la industria sigue hablando de “foo”, elegirá foo aunque sea un desastre total
Basta ver la arquitectura lambda, la mayoría de los proyectos de Apache, los contenedores, etc.