Desencanto con el software
(tonsky.me)- El software moderno, en vez de devolver los avances del hardware en forma de eficiencia, simplicidad y solidez, ha normalizado la ineficiencia apoyándose en la idea de que “la computadora ya es suficientemente rápida”.
- Incluso las tareas básicas se sienten más lentas de lo esperado: hacer scroll en la web, abrir un correo en Google Inbox en 13 segundos, una actualización de Windows 10 de 30 minutos o la latencia al escribir en un editor de texto.
- Un sistema Android de 6 GB, Windows 10 con 4 GB, Google Keyboard con 150 MB y los casos de apps Electron y Slack muestran cómo el hinchamiento de apps y plataformas termina costando rendimiento, complejidad y confiabilidad.
- Con el paso del tiempo, incluso software que antes funcionaba bien puede volverse lento o romperse, como ocurre con actualizaciones de SO, apps y navegadores, o con el fin del soporte para apps de 32 bits en iOS 11.
- Para crear mejor software, los ingenieros deben entender el rendimiento, la estructura y los límites de los sistemas que construyen, y lograr resultados rápidos y predecibles usando menos recursos.
Software que desperdicia rendimiento
- En el software moderno, muchas veces se acepta como normal que algo funcione usando apenas 1% o 0.01% del rendimiento posible.
- Mientras los autos, la arquitectura y la aviación se acercan a límites físicos o formas óptimas, el software justifica su ineficiencia con la idea de que “la computadora ya es suficientemente rápida”.
- El dicho “el tiempo del programador es más caro que el tiempo de la computadora” puede ocultar una realidad donde el tiempo de cómputo se desperdicia como nunca antes.
- Un tuit usado como ejemplo clásico del debate sobre eficiencia cuenta que reescribir en Rust un programa de Python que se ejecuta diario lo redujo de 1.5 segundos a 0.06 segundos, pero harían falta más de 41 años para recuperar 6 horas de trabajo.
Una experiencia básica insoportablemente lenta
- Las computadoras portátiles actuales son miles de veces más potentes que las de la era del alunizaje, pero incluso en una MacBook Pro reciente cuesta lograr scroll fluido en páginas web a 60fps.
- Inbox, creado por Google, tardaba 13 segundos en abrir un solo correo dentro de Google Chrome.
- Animar un recuadro blanco vacío en lugar del contenido se parece más a una concesión ante los límites de rendimiento de la web que a una solución real.
- Incluso ahora que las pantallas de 120 Hz ya son comunes, se considera que ni siquiera 60 Hz estables están garantizados al ver una sola respuesta en la web.
- Una actualización de Windows 10 tarda 30 minutos; en ese tiempo, se compara, podrías formatear un SSD, descargar e instalar una build nueva varias veces.
- Los editores de texto modernos tienen más latencia al escribir que Emacs, que ya tiene 42 años.
- Se señala que ni siquiera logran completar en 16 ms una tarea que solo requiere actualizar un pequeño rectángulo de la pantalla por cada tecla.
- Un juego 3D, en esos mismos 16 ms, renderiza toda la pantalla, procesa entradas, calcula el mundo y administra recursos.
- El hardware más rápido se está usando no para ejecutar software mejor, sino para correr software que hace lo mismo más lentamente.
Apps y plataformas infladas
- Una app web puede volverse 10 veces más rápida solo con bloquear anuncios, y AMP se parece menos a una tecnología nueva que a una solución de sentido común: quitar lo inflado.
- El sistema Android ocupa 6 GB incluso sin apps; Windows 95 ocupaba 30 MB y Windows 10 ocupa 4 GB.
- Windows 10 es 133 veces más grande que Windows 95, pero sus funciones básicas no son tan distintas.
- Android es incluso 1.5 veces más grande que Windows 10.
- Google Keyboard suele ocupar 150 MB, la app de Google 350 MB y Google Play Services 300 MB.
- La crítica se plantea preguntando si Google Keyboard, una app que dibuja unas treinta teclas en pantalla, realmente es cinco veces más compleja que todo Windows 95.
- Google Play Services no se puede eliminar aunque no se use.
- La situación en la que, tras instalar las apps básicas, queda apenas 1 GB libre para fotos contrasta con la época en que el SO, las apps y los datos cabían juntos en disquetes.
- Una app de tareas basada en Electron puede incluir hasta drivers para controles de Xbox 360, renderizado 3D, reproducción de música y captura de webcam.
- Slack, aunque se parece más a un chat con un editor de texto sencillo, se clasifica como app pesada por su velocidad de carga y uso de memoria.
- Cuanto más crecen las apps, mayor es la pérdida de control, el costo de complejidad, la caída de rendimiento y la deuda de confiabilidad; no deberíamos aceptar como normal las apps excesivamente pesadas.
Software que se pudre con el tiempo
- Hace 3 años, un teléfono Android de 16 GB bastaba, pero en la era de Android 8.1 las apps empezaron a duplicar su tamaño sin una razón especial y eso las volvió difíciles de usar.
- El iPhone 4s salió con iOS 5, pero ejecutar iOS 9 ya le cuesta trabajo, y se cuestiona que iOS 9 sea fundamentalmente mucho mejor.
- iOS 11 dejó de dar soporte a apps de 32 bits, lo que puede hacer que apps sin desarrollador activo o sin actualizaciones desaparezcan para siempre.
- Se cita un tuit: programas DOS siguen corriendo en muchas computadoras desde los años 80 sin cambios, mientras que una app en JavaScript puede romperse con la próxima actualización de Chrome.
- Incluso una página web que hoy funciona perfectamente podría no correr bien en ningún navegador dentro de 10 años.
- Seguimos comprando un teléfono nuevo y una MacBook nueva para hacer lo mismo, solo que ejecutando las mismas apps más lentamente.
Expectativas de calidad cada vez más bajas
- Cuando una página web falla, en vez de investigar la causa se le pide al usuario que recargue.
- Las apps web pueden lanzar errores “aleatorios” de JavaScript incluso en navegadores compatibles.
- Se critica que el diseño de páginas web y bases de datos SQL esté construido sobre la esperanza de que los datos no cambien mientras se mira la página renderizada.
- Las funciones colaborativas muchas veces se quedan en un nivel de “mejor esfuerzo”, incorporando escenarios cotidianos en los que se pueden perder datos.
- Un diálogo como “¿qué versión quieres conservar?” se parece más a pedirte que elijas cuál trabajo vas a destruir.
- Linux sigue siendo el sistema operativo más popular en servidores aunque su diseño permita matar procesos de forma arbitraria.
- Los casos de monitores Dell, AirDrop y Bluetooth muestran cómo el software interno de los dispositivos y especificaciones complejas terminan produciendo experiencias que dependen de resets periódicos o de la suerte.
- Para entregar algo que funcione de forma estable, hay que entender a fondo lo que se construyó, pero eso se vuelve difícil en sistemas excesivamente inflados.
Caos en las herramientas de programación y las prácticas de desarrollo
- Incluso en elementos básicos como gestión de paquetes, sistemas de build, compiladores, diseño de lenguajes o IDEs, cuesta encontrar resultados rápidos, eficientes y duraderos.
- Los sistemas de build, aun teniendo toda la información sobre los cambios, periódicamente exigen borrar todo y volver a empezar.
- Se plantea que no hay razón para que no puedan ser confiables, predecibles y reproducibles.
- Se describe a NPM como algo que durante años se mantuvo en estado de “a veces funciona”.
- Se cita un tuit donde
rm -rf node_modulesparece algo inevitable en el desarrollo con Node.js/JavaScript.
- Que se acepte que compiladores y tareas previas o posteriores tarden minutos u horas choca con la idea de que “el tiempo del programador importa”.
- Elegir Hadoop incluso cuando resulta más lento que ejecutarlo en una sola PC muestra que los programadores no siempre toman decisiones racionales.
- Se critica que el aprendizaje automático y la “inteligencia artificial” hayan llevado al software a una era de conjeturas poco confiables.
- Se cita un tuit que dice que cuando una app o servicio usa “inteligencia artificial” o “machine learning”, eso suele leerse como que será poco confiable, impredecible y difícil de explicar.
- Montar una VM sobre Linux y luego Docker dentro de esa VM se interpreta como señal de que ya no sabemos cómo mantener limpio el conjunto de programa, lenguaje y entorno de ejecución.
- Que el binario único de Go se considere una gran ventaja revela una situación donde basta con no ser un desastre para ser visto como éxito.
- Las dependencias aparecen al intentar resolver un problema simple con una “solución integral de paquetes”, arrastrando costo de adopción y nuevas dependencias.
- Se señala que es difícil usar un programa durante años sin reiniciarlo, y a veces ni siquiera durante unos pocos días.
- Reiniciar procesos, reiniciar bases de datos, usar watchdogs que relanzan apps cada 20 minutos, incluir recursos duplicados y comprimir para transmitir son formas de salir del paso en vez de arreglar el problema.
- Estas prácticas no son ingeniería, sino programación perezosa; la ingeniería consiste en comprender profundamente el rendimiento, la estructura y los límites de lo que se construye.
Complejidad acumulada y desinterés del mercado
- El software actual está formado por código que apenas funciona apilado sobre más código que apenas funciona, y sigue creciendo en tamaño y complejidad, reduciendo las oportunidades de cambiarlo.
- Un ecosistema sano necesita a veces retroceder para poder avanzar, pero se señala que en 25 años no hemos visto un kernel de SO nuevo, y ahora todo se volvió demasiado complejo como para reescribirlo.
- Lo mismo ocurre con los navegadores: por los edge cases y problemas heredados, resulta difícil reescribir desde cero un motor de layout.
- El progreso actual parece echarle más combustible al fuego: microservicios para resolver los problemas de los monolitos, Docker para resolver los problemas de los microservicios y Kubernetes para resolver los problemas de Docker.
- Se cita un tuit que dice que pasamos de configuración declarativa basada en XML a configuración de microservicios basada en YAML, aunque al menos el XML tenía esquema.
- Los usuarios no tienen más opción que aceptar lo que entregan los ingenieros, incluso frente a apps Android de 350 MB, scroll entrecortado o el clásico “si no funciona, reinicia”.
- Si todos los productos competidores son lentos, grandes y de baja calidad, es difícil que exista presión competitiva.
- A veces aparece algún producto que genera tensión competitiva, como iPhone/iOS frente a otros smartphones o Chrome frente a otros navegadores, pero se considera que ese efecto no dura mucho.
- La tarea de los ingenieros debería ser mostrar qué es posible, con las computadoras modernas, en términos de rendimiento, confiabilidad, calidad y disponibilidad.
Aun así, hay alternativas visibles
- LMAX Disruptor, SBE y Aeron de Martin Thompson se mencionan como ejemplos impresionantes, simples y eficientes.
- Xi editor de Raph Levien se valora como un proyecto hecho con los principios correctos en mente.
- Jonathan Blow creó un lenguaje para sus propios juegos, y en su laptop puede recompilar por completo 500 mil líneas de código en 1 segundo.
- Se aclara que no es build incremental ni caché intermedia, sino una recompilación completa desde cero.
- No hace falta ser un genio ni usar magia para escribir programas rápidos; basta con no construir sobre una montaña gigantesca de basura como las toolchains de moda.
Exigencias para un software mejor
- La ingeniería de software debe mejorar y no quedarse como está; no hace falta seguir rehaciendo lo mismo en versiones más lentas y más grandes.
- El desarrollo actual se parece menos a un progreso real que a un esfuerzo por apenas cumplir objetivos de negocio sobre herramientas destartaladas.
- Se señala que, por quedar atrapados en optimizaciones locales, nos acostumbramos a un estado inflado e ineficiente.
- Los ingenieros pueden —y deben— crear mejores apps con mejores herramientas, usando varias veces menos recursos, de forma rápida, predecible y confiable.
- Para entregar productos confiables, predecibles y de alta calidad, hay que entender completamente qué se hace y por qué; no se puede aceptar la excusa de “así es lo que nos tocó”.
2 comentarios
Este artículo ya tuvo una traducción al coreano hace tiempo, así que pueden consultar esa versión.
https://tonsky.me/blog/disenchantment/ko/
Lo dejé directamente como enlace a la traducción.
Opiniones de Hacker News
Por supuesto que es posible escribir código más pequeño, limpio, con menos bugs, más seguro, más rápido y más duradero. Si se logró en los comienzos de la era de la información, no hay razón para que no pueda hacerse ahora, con décadas de experiencia y herramientas potentes
La razón por la que no se hace es que no hay dinero en eso; de hecho, es casi lo contrario. Una startup financiada por VC tiene que salir primero al mercado para sobrevivir, y aun en organizaciones maduras, el costo y la hinchazón no son un problema, sino que funcionan como una forma de aumentar el prestigio de los gerentes. Al final, el costo se traslada al cliente
La razón por la que los “principios despiadados del mercado” no corrigen este desperdicio parece ser que, aunque una mejor base de código algún día podría obtener las llaves del reino, el entorno competitivo real es demasiado vulnerable a patologías y modas
Sin embargo, algo que sí se puede hacer más fácilmente que en una empresa financiada por VC es asignar tiempo a refactorización y manejo de deuda técnica. De hecho, ahora mismo frenamos en seco el desarrollo de nuevas funciones durante 45 días para abordar problemas técnicos importantes. Si esperas que te compren el año que viene, es difícil hacer una inversión así, y la deuda técnica pasa a ser problema de otro
Mientras el producto siga desarrollándose, seguirán apareciendo nuevos bugs y problemas. El “código perfecto” solo es posible en un contexto cerrado donde ya no se agregan nuevas funciones
Creo que el modelo de inversión de VC empujó a la industria hacia esto. Las startups reciben millones de dólares y, como tienen que generar dinero lo suficientemente rápido para devolverles a los inversionistas, deben exprimir la app lo antes posible. Todo lo que no tenga una métrica de ROI asociada no recibe la atención de nadie
Básicamente había acceso abierto, nada de contraseñas o contraseñas cortas, almacenamiento inseguro de contraseñas, todo en texto plano, ignorar la sanitización de entradas, cosas como telnet
Ahí también hay otra razón por la que el software se volvió más inflado. Empezamos a ver las interacciones y los riesgos, y una vez que los ves no puedes fingir que no existen. Los casos límite que hay que manejar no disminuyen, aumentan, y también hay más hardware que soportar
El proceso de escribir código de buen rendimiento puede mejorar, pero al mismo tiempo la línea base sube más rápido de lo que nosotros alcanzamos a llegar. También es interesante que ahora estemos avanzando poco a poco de nuevo hacia un mundo sin contraseñas
Una alta cobertura de pruebas unitarias que vuelve dolorosa la refactorización muchas veces estorba el lanzamiento de funciones, y creo que eso pasa mucho más seguido de lo que los fanáticos del desarrollo guiado por pruebas quieren admitir. Muchas de las “mejores prácticas” de la industria se parecen más a dogmas poco realistas creados por gente que trabaja en empresas que ya encontraron el encaje producto-mercado y donde el dinero se imprime solo
Todavía tengo una HP MS200 todo en uno que apenas se puede usar. La compré barata en una venta de garaje en 2017 y, al ponerle Linux, después de que cargara Chrome podía hacer videollamadas en pantalla completa con la versión web de Skype o ver YouTube en pantalla completa
Hace poco la recibí de nuevo y, antes de convertirla en computadora para un niño, instalé FC38 y la versión más reciente de Chrome; entonces los videos de YouTube se volvieron una presentación de diapositivas. Por más que cambié la configuración no funcionó, así que aumenté la RAM de 2 GB a 3 GB y volvió al mismo nivel de reproducción a 720p en pantalla completa de hace seis años
Es decir, para hacer lo mismo ahora se necesita 1,5 veces más memoria, 1 GB adicional. Entiendo eso de que 16 GB es el mínimo, pero incluso en esta máquina terrible, Chrome es casi un navegador web en reposo y muestra una huella de memoria de unos 30 GB. La mayor parte serán archivos mapeados con mmap, pero aun así son 30 GB
En cambio, en la mayoría de los dispositivos, el aumento de la duración de la batería, la menor temperatura y los menores requisitos de RAM y disco son mejoras evidentes. YouTube podría dejar duplicados en sus servidores los archivos con codificaciones antiguas, pero en una situación donde la mayoría de los usuarios accede desde dispositivos modernos, eso sería desperdiciar espacio
La mayor parte del aumento en el uso de RAM de Chrome viene de la evolución de su arquitectura de sandboxing. La memoria compartida y el espacio de procesos pueden usarse en ataques para escapar del sandbox, así que se agregó más aislamiento, y que Chrome levante un nuevo proceso independiente por cada pestaña y extensión también es una causa importante
Hoy en día, los bloqueadores de anuncios también influyen mucho. A medida que la web empeoró, hacer bloqueadores de anuncios efectivos se volvió más difícil y requiere más recursos. El software lento no se volvió lento solo para molestar a la gente; muchas veces es el resultado de convertir hacks peligrosos en buenas implementaciones y de cambios en los requisitos. FLV ya no es suficiente, y h264 tampoco parece que vaya a aguantar mucho dentro de cinco años si h265 y AV1 se generalizan
Las cadenas de herramientas modernas se enfocan en “no reinventar la rueda”, pero si cada dependencia eligió una versión distinta de la rueda, con solo traer unas cuantas dependencias terminas incorporando seis implementaciones de la misma función de bajo nivel
Eso sí, lo instalado era Flatpak y se sentía inflado. Por suerte, Chrome todavía puede instalarse directamente como RPM nativo y de hecho usa las bibliotecas compartidas del OS
Este texto ni siquiera toca el dolor central: los bugs. Casi todo el software se siente lo más lleno de bugs posible. Cada vez que tengo que usar software por una ruta poco común o en un flujo anormal, me da miedo, y casi siempre falla.
Hace poco, cuando vendí un auto en Carvana, apenas pude completar el trámite alternando entre Chrome y Firefox. En Chrome, el asistente de carga de imágenes lanzaba una excepción de JS, y esa parte milagrosamente solo funcionó en Firefox, pero el resto del sitio tenía tantos problemas que era evidente que no lo habían probado en Firefox.
Lo peor es que, cuando los usuarios no técnicos se topan con bugs, piensan que hicieron algo mal. Aunque sea pesado y lento, hoy estaría dispuesto a aceptar software estable y sólido.
Por otro lado, no dejo de ver lo lleno de bugs que está todo, y no sé si realmente hay más bugs que antes o si, al hacerme mayor y conocer mejor cómo son las cosas por dentro, tengo menos paciencia para el desarrollo de software al estilo de las grandes empresas. Me enoja ese product manager imaginario que dice “lancen la función X ya mismo”, aunque haya bugs evidentes de UX que se podrían detectar fácilmente.
Entiendo argumentos como el costo, el costo de oportunidad y el pragmatismo, y en parte estoy de acuerdo, pero a veces cuesta sacarse de encima la sensación de que simplemente aceptamos vivir en un mundo a medio construir.
No siento que hoy haya mejorado. Cuando niños pequeños agarran un teléfono o una laptop, pueden trabar, congelar y hacer crashear dispositivos modernos con bastante fiabilidad solo por presionar botones demasiado rápido o en un orden inesperado. Ni siquiera los están rompiendo físicamente, y aun así este es el estado de la tecnología moderna.
Entiendo por qué no se ha arreglado. La gente ya espera que a veces haga falta reiniciar, en estos casos es fácil culpar al niño, y reiniciar lo soluciona. Aun así, para este punto del ciclo de vida de los sistemas operativos, esperaba que ya fuera mejor.
En el artículo que escribí sobre C no lo dije, pero una de las grandes razones por las que uso C es que es difícil hacer software inflado. Se pueden agregar funciones, pero ni siquiera es fácil que una sola función sume 100 KB al ejecutable.
Ahora no estoy empleado, pero uso una máquina potente para “trabajar”. Aun así, uso Neovim y tmux en lugar de un IDE; no uso una distribución Linux típica, sino un Gentoo muy modificado; uso OpenRC en lugar de systemd; y en vez de un escritorio completo uso un gestor de ventanas en mosaico llamado Qtile.
Mantengo la máquina sin bloat, al punto de que al arrancar y apenas iniciar sesión solo hay 40 procesos. Ahora de verdad estoy haciendo ingeniería de software. Estoy intentando mitigar eficazmente los problemas de C y, al mismo tiempo, mantener el software pequeño y rápido, y espero algún día poder construir un negocio sobre eso.
Creo que veremos si todavía existe mercado para software ágil y sin bloat.
https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
https://gavinhoward.com/2020/12/my-development-environment-a...
https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...
Programas de los años 80 como WordPerfect, Lotus 123, MS-DOS 1.0 y SubLogic Flight Simulator antes de que Microsoft lo comprara estaban escritos en ensamblador. En esa época, observadores de la industria consideraban que, como MS Word y MS Excel estaban escritos en el “inflado” C, Microsoft podía iterar nuevas funciones más rápido y portarlos a otras arquitecturas más rápido que WordPerfect y Lotus 123. Sus competidores se quedaron demasiado tiempo en ensamblador.
Veo el mismo trade-off en el software personal. Si uso C#/Python, más de alto nivel y “más inflados”, en lugar de C/C++ más livianos, puedo terminar ciertas tareas mucho más rápido. Soy más competente en C++ y prefiero ejecutables pequeños, pero si C# me permite terminar antes lo que quiero hacer, esa ventaja deja de importar. Yo también soy parte del problema del software inflado.
“Voy a construir el puente más fuerte y liviano del mundo” es algo maravilloso; “voy a construir un puente lo suficientemente liviano y lo suficientemente fuerte a un costo que el cliente pueda pagar” es ingeniería.
Leí un poco más de la mitad y me detuve, pero el argumento central parecía ser que el software debe ser rápido, y no recuerdo ninguna justificación de esa filosofía más allá de la insinuación de que es “simplemente verdad”. Reconocía la objeción de que hay casos en los que las mejoras de eficiencia nunca compensan el costo en tiempo de perseguir la eficiencia, pero pasaba de largo sin lidiar realmente con ese argumento
Otra característica central del texto era seleccionar datos a conveniencia y simplificar en exceso el ámbito. Apela varias veces a la emoción con “¿qué diablos hace el software con todo ese tiempo y espacio?”, pero no intenta responder seriamente esa pregunta y usa el hecho de que no haya respuesta como si fuera evidencia de una respuesta equivocada. También compara varios programas que no tienen paridad de funciones como si solo difirieran en rendimiento
Hay mucho que decir sobre los costos sociales, ambientales y de negocio de la ineficiencia, y sobre el software más eficiente, pero también vale la pena discutir que el software moderno permite que personas que antes no podrían haber creado nada hagan algo “malo” que necesitan. Así como un ingeniero estructural elige algo “lo suficientemente resistente”, los desarrolladores modernos muchas veces apuntan a algo “lo suficientemente rápido”
Hay mucho material rico para debatir, pero este texto se quedó en la indignación emocional y no logró tratar con la razón y la argumentación reales. Algunas afirmaciones tienen algo de verdad, pero creo que el propio texto dejó claro que no tiene intención de debatir
También es muy probable que la red no sea 2G de unos pocos kbps, sino 5G de cientos de Mbps o fibra. Al final, las acciones pesan más que las palabras, y si la sociedad entera sigue el axioma de “software más rápido”, podemos aceptarlo como verdadero
En especial porque es un axioma que viene del mismo lugar que afirmaciones como “el tiempo del desarrollador vale más”; la única diferencia es de quién se está ahorrando el tiempo
Si los desarrolladores no prueban también en dispositivos de gama baja, no pueden enterarse del problema en absoluto. El verdadero problema no es tanto técnico, sino la actitud de algunos desarrolladores que se ponen a la defensiva y empiezan a discutir cuando se enfrentan a la verdad incómoda de que el código es demasiado lento. Hay que sentarse con el gerente de producto, reservar tiempo para profiling y optimización, y ver cómo mitigar los problemas de rendimiento sin rehacer todo desde cero
BASIC y SQL también tenían desde hace mucho el propósito de permitir que la gente creara algo “malo”, y lo mismo ocurría con Fortran y muchos lenguajes y tecnologías que hoy ya desaparecieron
Python o Java son, siendo generosos, conservadores; y si pensamos en los avances de los lenguajes de programación de los años 70, en realidad habría que llamarlos anacrónicos. J o Prolog están conceptualmente mucho más adelantados que Rust o Go, pero se crearon antes. Tampoco queda claro si C, acumulado desde C89 hasta C23, es un lenguaje moderno; si solo C23 es moderno; o si de verdad hay una gran diferencia entre C89 y C23
Me pregunto si hay otra forma de definir la modernidad que no sea el momento en que se creó algo o un árbol evolutivo imaginario
Es una queja vieja. Muchas comodidades que damos por sentadas tienen un costo, y ese costo se acumula mucho. Una pantalla 4K tiene 17 veces más píxeles que 800x600 y usa color de 32 bits, así que el tamaño bruto de los gráficos para pantallas modernas es unas 68 veces mayor
Antes bastaba con imágenes estáticas, pero ahora las animaciones de alta calidad y alto frame rate son el estándar. Arial Unicode es una fuente de 15 MB, y probablemente ni siquiera habría entrado en la memoria de la mayoría de las computadoras que corrían Windows 95
La corrección ortográfica en todas partes se volvió algo esperable, y cosas así se van sumando. Aun así, hacen que usar una computadora sea mucho más agradable. No extraño los modos de video de 16 colores ni la época en que no se podían usar dos idiomas que no fueran inglés al mismo tiempo sin rodeos muy molestos
Pero no quiero animaciones cuya única razón de ser es hacer que el tiempo de espera parezca menos aburrido. Unicode también vale el costo
Aun así, debería ser posible dibujar un glifo en pantalla en unos pocos milisegundos, como en 1981. Hay más píxeles y más glifos, pero es posible; simplemente no es una prioridad
Es parecido a pagar 100,000 dólares por un BMW de alto rendimiento y que el ingeniero te diga que tarda 30 segundos en acelerar de 0 a 60 mph, y que tengas que aceptarlo porque no eres experto en rendimiento
En mi organización actual vi una tendencia parecida. Al principio, cuando el equipo era pequeño, los detalles importaban. No podía ser lento, las animaciones tenían que ser fluidas, la velocidad de desplazamiento y los tiempos de carga importaban, e intentábamos crear el producto más eficiente para aumentar la eficiencia del usuario.
A medida que el equipo creció, el valor cambió hacia aumentar la eficiencia del desarrollador. Entraron más abstracciones, capas y frameworks, y se aceptó el compromiso de gastar millones de segundos de todos los usuarios a cambio de ahorrar un día de trabajo de un desarrollador.
La diferencia está en la visibilidad. La gerencia puede ver los costos de desarrollo, pero no ve los beneficios de un tiempo de ejecución un poco más rápido, un mejor caché o un desplazamiento más fluido. Porque no se miden. Cuando una organización llega al punto de preocuparse solo por números medibles, esta tendencia parece natural.
Claro, esto aplica hasta que la IA llegue al punto de poder arreglar todo lo que nosotros hicimos mal, o lo que la IA hizo mal, e incluso a la propia IA extremadamente ineficiente, como predice el artículo original.
Los autos solo se optimizaron después de un shock petrolero externo, y aun así de forma muy desigual. De hecho, los productos ineficientes suelen ser más rentables porque el cliente debe reemplazarlos con más frecuencia. Un pésimo cable de iPhone que se raja después de un año permite que Apple cobre por el reemplazo una y otra vez. Los electrodomésticos fallan con más frecuencia, pero se fabrican más baratos, lo que aumenta la ganancia por unidad. Lo importante no es la eficiencia de uso después de la venta, sino la eficiencia de producción.
En software, el capitalismo funciona lanzando nueva automatización lo más rápido posible y haciendo que el consumidor cargue con el desperdicio de energía y tiempo. La cadena de producción se estandariza y optimiza cada vez más, al punto de poder reemplazar a un desarrollador React o a un administrador de Kubernetes como si fuera un trabajador de almacén, lo que también genera presión salarial. Parte de la automatización es más bien autojustificación, como hacer que la terminología contable sea críptica para justificar un puesto; el resto tiene que ver con ganancias.
Todo tiene un costo. Si el costo computacional o la peor experiencia de usuario son lo bastante grandes, se optimiza la eficiencia. Los modelos de ML son un ejemplo. En otros casos no se optimiza, porque el usuario final no lo quiere al punto de aceptar menos funciones a cambio.
Los autos también consumían mucho combustible antes, pero cambiaron cuando el costo del combustible y las preocupaciones ambientales hicieron que los clientes quisieran otra cosa. Muchos ingenieros olvidan que se les paga para crear productos para los clientes.
Además, parece que el autor original nunca tuvo que esperar a que una máquina antigua con Windows o Linux terminara de arrancar por completo. Las versiones modernas arrancan mucho más rápido porque los clientes lo querían. Como los teléfonos están encendidos las 24 horas, a los clientes no les importa que arrancar una vez cada varios meses tarde mucho.
Mi BIOS tarda unos 20 segundos en hacer POST, y dicen que eso es normal. Después, el arranque del SO tarda unos 10 segundos.
También se podría decir que a médicos o ingenieros se les paga para desarrollar nuevos medicamentos o nuevas fuentes de energía, pero como estos campos son sensibles e importantes, existen varias capas de control gubernamental. El software todavía no tiene ese nivel de control.
Tienen el poder de moldear el entorno mismo, así que pueden redirigir en gran medida el resultado de la “demanda del cliente”.
Este artículo es de 2018, y ya hubo varias discusiones anteriores.
https://news.ycombinator.com/item?id=18012334 (sep. 2018)
https://news.ycombinator.com/item?id=21929709 (ene. 2020)
https://news.ycombinator.com/item?id=31798580 (jun. 2022)
Estoy muy de acuerdo. Como desarrolladores, es importante recordar que tenemos opciones. No podemos elegir en todo, pero sí podemos escoger alternativas menos malas.
No es obligatorio usar Node. También se puede escribir software excelente y retrocompatible en .NET o en el ecosistema JVM, y esperar que siga funcionando dentro de 10 años sin modificaciones.
Tampoco es obligatorio crear páginas web de una sola página. El HTML a la antigua, que recarga toda la página con cada clic, funciona bien, y a estas alturas incluso podría tener menor latencia.
Tampoco es obligatorio crear apps de escritorio con Chromium. Arrancar con un framework de UI requiere un poco más de trabajo, pero la calidad vale la pena. No siempre tenemos poder de decisión, pero cuando lo tenemos, debemos alejarnos de las malas decisiones.