"El software se está volviendo más lento con más rapidez de la que el hardware se vuelve más rápido."
Los desarrolladores debaten si la “ley de Wirth” —que el software se vuelve más lento más rápido de lo que el hardware se vuelve más rápido— sigue siendo válida, señalando apps web hinchadas, herramientas basadas en Electron, suites de seguridad pesadas y saltos de red de SaaS como evidencia de que las máquinas modernas a menudo no se sienten más ágiles que las antiguas. Muchos ven la causa raíz en los incentivos: las empresas recompensan la entrega rápida de funciones y la reutilización multiplataforma por encima del perfilado, la eficiencia algorítmica y las pruebas en hardware de gama baja, aunque los usuarios sufran habitualmente por la latencia y clientes que consumen muchos recursos. Otros responden que los SSD, las CPU multinúcleo y mejores herramientas han hecho que la informática cotidiana sea notablemente más rápida en general, y que algunos stacks y bibliotecas modernos de hecho se están volviendo más eficientes.
Hardware de desarrollador vs. realidad del usuario
- Muchos sostienen que los desarrolladores deberían usar con regularidad máquinas de gama baja o VMs limitadas a especificaciones del “5.º percentil” para sentir el dolor real del usuario y priorizar el rendimiento.
- Otros dicen que esto es contraproducente: los stacks modernos de desarrollo (IDE, Docker, bases de datos, Node, etc.) ya cargan demasiado incluso a máquinas buenas; ralentizar el hardware solo desperdicia tiempo caro de los desarrolladores.
- Compromiso sugerido: una máquina de desarrollo rápida, pero ejecutar el producto en sí en VMs/teléfonos con recursos limitados o en máquinas de prueba dedicadas de baja especificación.
Rendimiento vs. funciones e incentivos de negocio
- Tema repetido: las empresas, no los desarrolladores, fijan las prioridades; las funciones y los plazos casi siempre vencen al rendimiento.
- Los usuarios a menudo piden nuevas capacidades por encima de la velocidad, especialmente cuando las funciones pueden ahorrar días mientras que las mejoras de rendimiento ahorran horas.
- Algunos temen que esto refleje la paradoja de Jevons: las ganancias de eficiencia simplemente se gastan en más funciones y capas, no en capacidad de respuesta.
De dónde viene la lentitud
- Culpables mencionados con frecuencia: hinchazón web, apps de Electron, frameworks excesivos, SaaS/saltos de red, consultas N+1 en bases de datos, índices faltantes y arquitecturas demasiado abstraídas.
- Otros señalan que, en entornos empresariales, el “software a medida” puede ser peor que componentes eficientes y bien elegidos de catálogo.
- Las herramientas de seguridad, la telemetría y el “corporate-ware” se describen como grandes drenajes de E/S y CPU.
¿Es realmente cierta la ley de Wirth?
- Algunos dicen que sí: las apps cotidianas, las UIs y las operaciones simples a menudo no se sienten más rápidas a pesar de mejoras de hardware de órdenes de magnitud; se citan ejemplos de latencia de entrada y móviles lentos.
- Otros responden con anécdotas de máquinas modernas baratas que se sienten mucho más rápidas que PCs de mediados de los 2000, especialmente con SSD y mejores redes.
- Varios señalan la falta de mediciones longitudinales rigurosas; la mayor parte de la evidencia es anecdótica.
Cultura de la optimización y lenguajes
- Algunos sienten que “la optimización es la raíz de todo mal” se ha usado mal para justificar no optimizar nunca, y que muchos equipos no perfilan ni miden en absoluto.
- Otros sostienen que la optimización sigue valorándose donde importa (juegos, herramientas de datos, bibliotecas orientadas al rendimiento como ecosistemas Python más rápidos), pero que los casos de negocio suelen ser débiles.
- El hilo destaca mejoras clásicas de rendimiento: mejores consultas a BD, índices, menos llamadas de red y evitar capas de abstracción innecesarias.
Direcciones futuras y herramientas
- La gente sugiere herramientas de limitación de red/CPU, CI en hardware lento y conjuntos de datos realistas como formas prácticas de mantener el rendimiento bajo control.
- Las opiniones se dividen sobre si el código generado por IA empeorará la hinchazón (salida más rápida de “funciona pero lento”) o ayudará a optimizar, según cómo se use.