La crisis del software
(wryl.tech)- La expresión “software crisis”, surgida en la NATO Software Engineering conference de 1968, se usa menos hoy, pero la carga creada por la complejidad y la abstracción del software sigue presente
- Edsger Dijkstra, en su conferencia del Turing Award de 1972, consideró que mientras el rendimiento y la complejidad del hardware crecían rápidamente, los métodos organizativos para manejarlos no lograban seguirles el ritmo
- La comercialización de la computación personal y los ciclos de lanzamiento rápidos hicieron que los usuarios quisieran más capacidad antes de dominar lo suficiente sus herramientas, y “abstract it away” se volvió la reacción por defecto
- Las capas de abstracción anidadas generan costos de rendimiento y modelos mentales distorsionados, y dificultan el acceso a funciones básicas de la máquina como gráficos y sonido
- La solución no está en volver a las plataformas limitadas del pasado, sino en reducir las capas de abstracción y preservar la información entre capas para devolverles el control a quienes usan las herramientas
La preocupación de 1968 todavía no termina
- En la primera NATO Software Engineering conference de 1968 se acuñó el término “software crisis”
- Esas conferencias fueron uno de los primeros intentos de ordenar y sistematizar las prácticas de programación de máquinas de cálculo automático
- El 16 de julio de 1969 se lanzó la misión Apollo 11, y en octubre de ese mismo año se celebró la última NATO Software Engineering conference
- Edsger Dijkstra, en su conferencia del Turing Award de 1972, ubicó la causa de la crisis en las máquinas cada vez más potentes y en la ausencia de métodos organizativos capaces de lidiar con ellas
- Dejó una idea en el sentido de que “cuando no había máquinas, la programación no era un problema; cuando había unas pocas computadoras débiles, era un problema menor; y cuando aparecieron computadoras gigantes, la programación también se volvió un problema gigantesco”
- Hoy, en la práctica de la programación, la expresión “software crisis” no aparece con frecuencia
- El desarrollo de nuevos lenguajes y métodos organizativos, junto con la distancia temporal respecto de los problemas del pasado, llevó a la industria a sentir cierto alivio, como si ya los hubiera resuelto en alguna medida
- Pero ese alivio permanece más cerca de la derrota y la aceptación que de una verdadera comodidad
La abstracción aleja el control del usuario
- Los avances de la computación temprana y de campos cercanos ocurrieron en máquinas y entornos donde construir una torre de abstracciones tenía un costo directo
- Cuando no era posible esquivar las restricciones, existía un ciclo de crecimiento acompañado por actualizaciones de hardware
- En la práctica, se terminaba deseando más capacidad antes de comprender lo suficiente las restricciones actuales
- Tras la comercialización de la computación personal, las empresas que vendían equipos no esperaron a que los usuarios dominaran por completo sus productos, y el ciclo de crecimiento siguió acelerándose
- Junto con los ciclos rápidos de lanzamiento de hardware, “abstract it away” se convirtió en la forma de pensar por defecto
- Si se empujan los detalles que no gustan dentro de una estructura controlable, se obtiene cierto grado de independencia, pero con un costo de rendimiento
- Las múltiples capas de abstracción y el ocultamiento de información trasladan el problema de construir software a niveles más altos
- Esas capas se integran en el software necesario para usar computadoras y en el software que mueve la vida cotidiana
- La industria del software en general aceleró los ciclos de lanzamiento y la influencia del capital, y se redujo el margen al que un desarrollador individual puede acceder fácilmente
- La crisis del software no es solo un problema de desarrolladores: también se extiende a los usuarios de software
- Los usuarios tienen muy poco control fuera de las funciones permitidas por quienes lo escribieron
- Se difumina el hecho de que tanto crear como usar software son actividades humanas
No hay que volver al pasado, sino a capas más superficiales
- La solución propuesta no consiste en volver a plataformas más limitadas
- Hay que limitar la cantidad de capas de abstracción permitidas
- Es necesario preservar la información entre capas
- El modelo de programación, la interfaz de usuario y el hardware subyacente deben ser superficiales y combinables
- Movimientos como las comunidades Handmade, Permacomputing y de retrocomputación contribuyen a aumentar la conciencia sobre la crisis del software
1 comentarios
Opiniones de Hacker News
Hola, soy el autor. Me parece importante aclarar algunos puntos que suelen malinterpretarse en este artículo. No me opongo a la abstracción en sí, sino a aplicarla sin límites
La solución tampoco es volver a plataformas más restrictivas, ni sostener que los usuarios deberían “aguantarse y volverse más técnicos”. La clave para entender la crisis del software está en las curvas de “dominio de la plataforma” y “ciclo de crecimiento/lanzamiento”. Durante más de 40 años, salvo en algunas áreas, esas curvas se fueron separando; no lo resolvimos cuando estaban cerca, pero el segundo mejor momento es ahora
También hay quienes reaccionan diciendo que este artículo es clickbait, pero es la primera entrada de mi blog y contiene mis ideas sobre la situación en la que estoy como desarrollador. Sentimientos parecidos aparecen de distintas formas en varias comunidades, especialmente en algunas comunidades de base contracultural. Quiero mostrar parte de la solución al problema, así que también pienso escribir una entrada de seguimiento del tipo “voy a mostrar cómo hacerlo”. Es algo que hago solo, así que les pido tiempo y paciencia
Mientras haya millones de personas creando software, este problema no se puede arreglar por completo. Inevitablemente uno va a discrepar con parte de ellas, y no todos pueden llegar a ser tan hábiles como el autor. Por eso, este artículo termina leyéndose como un argumento de que el estándar de lo que cuenta como “abstracción aceptable” debería ser más alto que ahora
Es fácil hablar en grande, pero si uno mira de cerca áreas específicas que considera “demasiado abstraídas”, probablemente termine con más humildad. Esas “abstracciones excesivas” suelen tener razones bastante buenas, y los ingenieros de esas áreas también sienten que la situación de las abstracciones es desordenada, pero la consideran necesaria o poco realista de arreglar
Por ejemplo, mucho software se construye poniendo una buena abstracción sobre abstracciones intermedias muy usadas. Kubernetes se monta sobre Linux, runtimes de contenedores y una estructura tradicional de plano de control/capa de configuración/plano de datos. También se podría implementar toda esa lógica directamente en un nuevo sistema operativo, pero aparecerían problemas de compatibilidad para los usuarios. Podrías construirlo, pero quizá no tendrías usuarios; y entonces tendrías que volver a implementar las malas abstracciones que querías evitar. Además, una solución así es mucho más difícil de implementar. No me gusta el diseño de Kubernetes y quisiera resolver este problema, pero lo veo como un caso en el que hacerlo “de la manera correcta” es tan difícil o caro que deja de valer la pena
Según el momento y el trasfondo con que hayas entrado en este campo, es muy probable que las abstracciones de generaciones anteriores ya se hayan incorporado como prácticas aceptadas. Por ejemplo, en cierto momento se volvió un supuesto obvio usar un sistema operativo con un sistema de archivos de propósito general
Creo que el problema del que se habla ahora se parece más a las dificultades que uno encuentra al entrar actualmente en este campo. Si se asume que hay que entender en detalle todas las abstracciones en uso para poder contribuir, los conocimientos previos requeridos son considerables. Puede ser abrumador, pero también existe el camino de aceptar las abstracciones hasta poder entenderlas con más profundidad
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
Dicho eso, creo que la razón por la que esta situación no cambia es claramente económica. No quiero decir que el mal software sea más barato. Pero recortar esquinas permite que una persona u organización ahorre costos ahora, mientras que los costos mayores los termina cargando más adelante la propia organización, sus clientes o la sociedad en conjunto, así que hay un fuerte incentivo hacia prácticas baratas y malas. Además, al software le cuesta encajar en los criterios de otras ramas de la ingeniería, por lo que también es difícil crear contratos o regulaciones que exijan software de cierto estándar o calidad
La única solución imaginable sería una revolución tecnológica que permita crear software más barato y mejor con la misma tecnología y que, al mismo tiempo, impida crear software más barato y peor
Hay demasiado software en demasiadas plataformas, y el panorama está demasiado fragmentado como para hacer generalizaciones. Algunos proyectos tambalean y se derrumban, mientras que otros funcionan bien
También hay software hostil hacia el usuario, pero eso es intencional por diseño. Detrás hay cinismo y codicia. No es que los programadores no sepan lo que hacen, sino que hacen lo que se les ordena
Los propios usuarios también lo fomentan. Aunque les des buen software, no les interesa; los usuarios piden otras cosas, no buen software. Un usuario que quiere buen software termina siendo víctima de cincuenta usuarios que no lo quieren. El software de mercado masivo ya es cultura de masas
Word de esa época tampoco era tan inferior frente a la versión actual. Pero ahora Windows y Office necesitan entre 50 y 100 GB de disco apenas para funcionar. ¿Qué obtuvimos para que el tamaño se multiplicara por 1000?
Es una locura absoluta, pero la dejamos pasar. Los sistemas modernos tienen unas 5000 a 10000 veces más disco, RAM y CPU, y el internet doméstico es literalmente un millón de veces más rápido que los primeros módems
Este texto parte de la premisa de que la crisis del software existe realmente o es un problema grave. Como elementos de la crisis menciona sobrecostos, retrasos, ineficiencia, baja calidad, incumplimiento de requisitos, proyectos inmanejables, código difícil de mantener y entregas incumplidas.
Pero si quitamos de ahí la palabra “software”, ¿cuántas actividades humanas no sufren al menos uno de esos problemas? A la inversa, también hay mucho software bastante excelente. Tendemos a fijarnos solo en los fracasos y los defectos, mientras ignoramos los éxitos como si fueran una línea base obvia, aunque sigan mejorando.
Desde que presionas el botón de encendido de una computadora hasta llegar al escritorio, ya pasas por cientos de abstracciones. Ese escritorio por sí solo es el objeto más complejo con el que interactuaremos durante todo el día. Esto ocurre miles de millones de veces al día en todo el mundo y, en general, funciona sin problemas. Y esto es apenas un ejemplo muy pequeño.
Sin embargo, creo que la verdadera motivación de textos como este no son esos puntos, sino la sensación de que todo resulta imposible de manejar. Un programador con experiencia tiene que equilibrar esa sensación abrumadora con el trabajo que hay que hacer. Me tomó tiempo llegar a esto, pero creo que es importante. Nunca va a estar todo completamente ordenado, y hay que aceptar ese hecho.
En el software casi no existen esos límites, salvo las restricciones de rendimiento y memoria. Pero ambas suelen ser tan holgadas que se puede seguir apilando basura indefinidamente para salir del paso. Todos hemos tenido momentos en los que pensamos o dijimos: “¿cómo demonios funciona esto?”. Hasta que el usuario pisa una condición de borde equivocada, no sabemos cuán precario es el código que hay debajo.
“¿Ya probó apagarlo y volverlo a encender?” es la prueba de eso. Los sistemas de software suelen entrar en estados malos tan sutiles y desconocidos que la única solución es borrar todo y volver a levantarlo desde cero. Como cuando el teléfono sigue vibrando después de una llamada hasta que llega la siguiente llamada o mensaje, cuando en una app web una parte no carga al 100% y desaparecen opciones, o cuando el emparejamiento Bluetooth funciona de manera irregular.
La comunicación es la forma de propagar la comprensión y corregir su falta, y la comprensión es la base del éxito en cualquier tarea. Sin comprensión, aparece uno o más de los síntomas anteriores. Incluso con comprensión pueden aparecer, pero al menos existe un camino hacia el éxito.
Según mi experiencia, la mayoría de los problemas de la industria de la ingeniería de software son problemas de personas. No son la tecnología, ni la técnica en sí, ni los procesos. Por eso la comunicación y la comprensión son esenciales para el éxito.
Si uno mira la trayectoria de los líderes de empresas de ingeniería o automotrices, se ve una progresión en la que fueron asumiendo responsabilidades cada vez mayores en el diseño de piezas, componentes y productos, o en la operación de instalaciones de producción. Incluso el CEO sigue destacando el conocimiento técnico, y el personal no técnico al menos finge hacerlo
En cambio, en el desarrollo de software ágil, la competencia técnica por lo general termina en el nivel más bajo. En un equipo Scrum están las personas que hacen software, y eso es todo. Es muy probable que muchos Scrum Masters y analistas de negocio nunca hayan programado mucho, y el primer jefe real en la jerarquía suele hacer sobre todo tareas administrativas y de secretaría, así que casi no ve código
El punto no es solo que el desarrollo de software se haga en unidades del tamaño de un ticket, lo que dificulta reflexionar filosóficamente sobre cuántas capas de abstracción uno crea y mantiene. Los desarrolladores de software ni siquiera tienen un lugar en la mesa de decisiones. Los cuida un Scrum Master, ceden en las revisiones de código, reciben presión para no pensar fuera del ticket, y por lo general tampoco tienen una ruta de ascenso que lleve su competencia técnica al liderazgo
Por eso parece muy probable que el movimiento que intenta alertar sobre la “crisis del software” se quede, como dice el texto al final, en ámbitos de hobby como Handmade, Permacomputing y la computación retro. Creo que Hollywood también tiene parte de la culpa, al retratar constantemente a la gente de software/IT de forma humillante, mientras da infinitos papeles protagónicos a médicos y abogados y convierte su jerga profesional compleja en historias interesantes. ¿De verdad en nuestro caso es imposible? Quizá pronto una IA para escribir guiones logre algo
El desarrollo de software consiste en conversar todo el día con una computadora de manera estricta. Resuelve tareas ordinarias ya resueltas en una aplicación nueva, o trata problemas que son difíciles siquiera de captar sin contexto técnico. Soy desarrollador y programo por diversión desde hace más de 20 años, pero la mayor parte del trabajo es aburridísima. Ni siquiera intento explicársela a quienes no son desarrolladores. Es tan poco entretenido como la contabilidad, y probablemente mucha gente obtendría información más útil de otra historia
La empresa más metida en agile en la que trabajé trataba a juniors y seniors como engranajes intercambiables. La única diferencia era que los seniors tenían que procesar más puntos por sprint. Había una inhibición activa contra pensar fuera del alcance del ticket, y el ambiente era de agachar la cabeza y cerrar la boca
Pero hay dos problemas. No pueden meterse a fondo en los detalles de implementación, y además están atados a incentivos distorsionados que recompensan generar complejidad. Claro que hay quienes se oponen a eso, pero esas personas tienen pocas probabilidades de ascender. A uno no lo recompensan por reducir la cantidad de gente debajo suyo ni por eliminar su propio rol
Si tuviera que resumir por qué los desarrolladores solo manejan porciones de requisitos reales del tamaño de un ticket, diría que es porque son demasiado tontos. No pueden tener el conjunto completo en la cabeza, no lo entienden. ¿Suena frustrante? Lo es. De verdad es difícil de entender. Lo siento
Este texto pinta la abstracción como un mal, pero es una herramienta inevitable si queremos crear software hecho por humanos que tenga capacidades por encima de cierto nivel
Rich Hickey dijo algo en el sentido de que “un malabarista principiante puede manejar dos o tres pelotas, pero incluso el mejor malabarista del mundo probablemente tenga un límite de unas nueve. La capacidad humana no varía por órdenes de magnitud y enseguida toca techo”. Para superar ese límite, no queda otra que abstraer
Por supuesto, en casos concretos puede haber malas abstracciones o demasiadas abstracciones, y creo que eso es lo que enfurece al autor. Pero esa distinción es importante
La parte de “ahora no es fácil crear software, y nada viene con manual” es claramente falsa. Crear software es más fácil que nunca, y la documentación también está mejor preparada
Para entender un todo complejo no hace falta necesariamente la indirección. Para manejar la complejidad hay que desenredar lo enmarañado y poder entender cada parte de manera independiente. Si ocultamos la complejidad mediante indirección, se crea distancia entre nosotros y aquello sobre lo que debemos razonar
La abstracción es buena para el usuario, porque no tiene que preocuparse por los detalles, sea desarrollador o no. Pero no nos facilita el trabajo de construirla
Contrario a la idea de que “ahora ya no es fácil crear software”, es muy fácil si conoces la herramienta correcta para la tarea correcta. El problema es que la información sobre esas herramientas está reprimida y casi no se escucha hablar de ellas
El ecosistema de herramientas tecnológicas que la mayoría imagina y cómo es en realidad son cosas muy distintas. La mayoría de las herramientas que conocemos son terribles. Intentan parecer soluciones universales, pero en la práctica no son muy buenas para nada. Aun así, son las herramientas más populares. Como sugiere el texto, creo que es por la influencia del capital
Por ejemplo, con la herramienta que uso ahora, grabé un video en el que construyo desde cero en 3 horas una app de marketplace relativamente compleja, con inicio de sesión, control de acceso, validación de esquemas y vistas con filtros complejos, solo desde el navegador, sin descargar ningún software y en modo serverless. La app completa tiene menos de 700 líneas de marcado HTML y 12 líneas de JavaScript. Tuvo unas 10 vistas
A diferencia de ese giro conspirativo, las herramientas modernas son más flexibles y fáciles de usar que nunca. Tienen defectos, pero no son nada comparado con lo que tenían que soportar los desarrolladores hace décadas. No hay una gran conspiración para tapar tu herramienta
Creo mucho en el no-code/low-code y en herramientas que puedan ejecutarse en cualquier lugar. Aunque quizá lo que quiero decir con eso no sea lo mismo que tú piensas. En cualquier caso, reconozco que lo hayas creado
Al empezar a ver el video, las primeras preguntas que me surgieron fueron estas: ¿qué es Codespaces? ¿Qué pasa con la seguridad? ¿Dónde se ejecuta la app final? ¿Puedo ejecutarla en mi propio hardware? ¿Puede funcionar sin acceso a la nube? ¿En qué nube? ¿Seguirá existiendo la próxima semana, el próximo mes, el próximo año, dentro de 10 años? Claro, no te preocupes demasiado por una sola muestra
La situación del no-code/low-code puede compararse con la autoedición de escritorio. En DTP no hay pipelines de CI/CD. Presionas imprimir y listo. Es un entorno completamente integrado. En cambio, literalmente todos los entornos de “integración continua” parecen devorarse a sí mismos de tanto esforzarse por gritar. En algún lugar habrá herramientas para separación de colores, configuración de márgenes, importación de fuentes, bibliotecas de encabezados PostScript o generación de LaTeX, pero la mayoría ni las ve ni las usa. En algún lugar también habrá gente haciendo impresión multipasas que solo se ve nítida bajo luz natural, con pigmentos mucho más variados que CMYK, pero a la mayoría no le importa porque solo ve capturas mediocres en el celular
Esto no es solo un problema de los creadores. Los consumidores no saben qué es posible, y tampoco tienen dispositivos que revelen todo el rango de posibilidades. Los dispositivos de consumo perjudican activamente ese rango por muchas razones de ecosistemas cerrados y por simple descuido e ignorancia
Hace unos años me dieron un Cadillac como auto de renta, y nunca compraría un Cadillac moderno; si puedo evitarlo, tampoco lo manejaría. No podía controlar los limpiaparabrisas, y la pantalla de la consola me mostró varias veces la advertencia más llamativa de que yo no estaba mirando la carretera. Probablemente no se dio cuenta de que usaba anteojos. Iba en tráfico rápido por una carretera desconocida, así que en realidad no miré la pantalla y le pregunté a mi acompañante: “¿Qué diablos dice esa pantalla que parpadea?”. Bien hecho, Cadillac
Las estructuras superficiales y componibles son algo que todos experimentamos al usar herramientas UNIX
Aquí es donde la GUI se viene abajo. Las GUI son literalmente islas que no se comunican entre sí de una forma componible
Estoy experimentando con una herramienta llamada guish para mezclar la idea de las GUI con los pipelines de shell
https://github.com/williamcotton/guish
Me pregunto si alguien conoce herramientas similares o enfoques de GUI componibles
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
Yo también estoy trabajando en ideas relacionadas con esto, y por fuera quizá se parezcan a lo tuyo. Pero te recomiendo ver cómo funciona esto en emacs. No lo he analizado a fondo, pero tu enfoque no parece muy “componible”
Si no lo conoces, esto también puede servir de inspiración: https://gtoolkit.com/ Es un entorno Smalltalk donde, como en emacs, literalmente todo es programable, pero casi en la dirección opuesta. La GUI no es el resultado de los comandos, sino el lenguaje en sí
Pero el problema más grande no es la GUI. La GUI también es un problema, pero como necesariamente está en la cima de la pila de abstracciones, el problema no sigue propagándose y componiéndose. Curiosamente, es un problema tan grande que termina dejando de ser un problema
El elefante enorme de hoy son los sistemas distribuidos
Dicho eso, la GUI ha sido un punto débil desde hace mucho tiempo. Creo que se debe a que, para que una UI sea buena o no, hay muchas consideraciones “globales”, así que no es una propiedad modular
Personalmente, me gustaría que hubiera más UI, pero manteniendo la automatización. Esa propiedad de poder guardar en un archivo lo que escribiste en la shell para ejecutarlo de nuevo después, modificarlo y volverlo a ejecutar, o copiar un comando y enviárselo por email a un amigo
Para dar contexto, llevo años construyendo una shell desde cero y tiene un modo headless para GUI. También hay demos reales hechas por otras personas, aunque ahora nadie está trabajando en ello
Capturas de pantalla:
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
Hay más links aquí - https://github.com/oilshell/oil/wiki/Interactive-Shell - también hay proyectos inactivos interesantes como Xiki
Si necesitas una shell compatible separada de la terminal, o una shell nueva de ese tipo, avísame por email o en https://oilshell.zulipchat.com
Básicamente necesitamos gente que pruebe el protocolo headless y nos diga qué mejorar. Creo que hay que crear una GUI de shell que “tenga” una terminal, pero que no “sea” la terminal en sí. Parece relacionado con lo que estás construyendo
Ahora estoy trabajando sobre todo en el nuevo lenguaje YSH, pero también me gustaría revivir el trabajo de GUI. No tengo mucha experiencia como programador de UI, así que vendrían bien otras perspectivas
Y me da gusto que hayas incluido ggplot, porque me gusta. De hecho, ggplot es justamente uno de esos puntos donde desearía que hubiera gráficos en la shell
La frase final “puede mejorar. Les mostraré cómo” simplemente parece una introducción de clickbait
La frase “es muy raro que estos modelos reflejen la realidad; cuando lo hacen, es una feliz coincidencia, y cuando no, es un desastre” no coincide con mi experiencia.
En general, la mayor parte del software disponible en el mercado no es crítico. Muchas apps web infladas y mal hechas pueden pasarse el día absorbiendo una cantidad absurda de recursos, mostrar bugs irregulares por todos lados y aun así cumplir pésimamente con lo que el usuario esperaba. Todo eso es cierto.
Pero no son tan críticas como el software que maneja marcapasos o cohetes espaciales. La mayor parte del software puede ser un desastre. Porque la mayoría de los proyectos tienen que ver con los caprichos humanos, y lo peor de la falta de calidad suele ser algo de frustración, no una catástrofe ni la muerte.
Además, la mayoría de los desarrolladores de software probablemente tampoco trabaja bajo incentivos económicos al estilo Silicon Valley, ni se gana la vida con proyectos que le apasiona crear. La mayor parte del software que llega al mercado se produce mediante estructuras de recompensa externas y pésimas. ¿Qué esperarían que saliera de ese proceso, si no basura?
Detesto de verdad los escalones faltantes.
Estamos muy alejados del uso real del software que creamos, y solo experimentamos señales ejecutables y breves que informan el proceso de desarrollo. A menos que pudiéramos intercambiar cuerpos con un usuario nuevo, es difícil sentir de verdad el dolor real de esta “muerte por mil cortes”.
Veo la programación como un oficio, y creo que tenemos el poder de gobernar la calidad del software. Solo que hay incentivos, financieros o no, que nos llevan a mirar hacia otro lado.
No creo que haya una crisis del software. Millones de programadores en todo el mundo crean programas más o menos útiles, y casi todo, hasta las tostadoras, ejecuta software con suficiente éxito. La comunidad también ha creado programas accesibles para todos, desde niños de 5 años hasta abuelos. ¿Dónde está la crisis?
Pero sí hay una crisis de gestión de proyectos. No se limita al software: es el problema de la distancia entre quienes planifican y quienes entregan. Y parece que no logramos cerrar esa brecha. Agile, Scrum, etc. son indicadores de esa brecha en la que los “gurús” nos tratan a todos como tontos, y nosotros tampoco estamos logrando crear algo mejor.
La mercantilización del desarrollo de software también contribuye a este caos. Por la naturaleza de un campo con una barrera de entrada baja, personas de todos los niveles pueden participar con tasas de éxito diversas. No es una cuestión de bueno o malo, sino la naturaleza del fenómeno. No es muy distinto de que en la industria gastronómica existan tanto restaurantes con estrellas Michelin como MacDonalds, y ambos tengan consumidores. Y aun así no lo llamamos una crisis de los restaurantes.
Esto reduce la vida útil de la tostadora. Antes tal vez había tostadoras que duraban 10 años. Ahora, por mal software y quizá por una conexión WiFi o Bluetooth forzada, cuando el proveedor deja de actualizarla, se convierte en basura a los 2 años. Puede que ni siquiera haya tenido actualizaciones. La crisis no siempre se ve porque no es directamente visible, o por el sobreconsumo actual y la compra interminable de productos nuevos.
Si la tostadora deja de funcionar después de 2 años, nos parece aceptable, y quizá no nos importa ni sabemos por qué. Pero tal vez fue parte de la botnet Mirai https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
Probablemente no, porque las tostadoras usan chips más simples, pero quién sabe.
Como referencia, mi tostadora Dualit no ejecuta software.
El pasaje “desarrollamos una forma de apilar capas de abstracción anidadas y ocultar información en varios niveles; convertimos el problema de construir software en capas que se elevan imponentes” me hace pensar en las abstracciones con fugas y en la Torre de Babel.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
Vale la pena compararlos entre sí.