Fast - El poder del software rápido

• En el desarrollo de software rara vez se pide rapidez (fast), pero el software rápido cambia el comportamiento de los usuarios
• Tecnologías como los despliegues rápidos y el streaming en tiempo real mejoran de forma revolucionaria la eficiencia laboral y el trabajo remoto
• El software lento genera fricción cognitiva y, en la práctica, reduce mucho la productividad de los usuarios
• El software rápido no oculta la complejidad, sino que demuestra simplicidad y enfoque
• De ahora en adelante, en la industria del desarrollo se fortalecerá la tendencia a priorizar la optimización del rendimiento y de la experiencia

---

Una industria del software que no exige rapidez

• En la industria del software normalmente se piden funcionalidad, precio, integración de datos, etc., pero rara vez se exige de forma directa la “rapidez”
• Sin embargo, el software rápido tiene el poder de cambiar el comportamiento mismo de los usuarios
• Si el tiempo para desplegar código se reduce a segundos, también aumenta la frecuencia de despliegue de los desarrolladores
• Las funciones de autocompletado de código basadas en inteligencia artificial facilitan el prototipado en lenguajes poco familiares
• La tecnología de streaming en tiempo real abre nuevas posibilidades para el trabajo remoto

Los límites del software lento

• El software lento impone más restricciones de las que creemos
• Por ejemplo, al usar WiFi en un avión es difícil lograr un trabajo realmente productivo
  • Apenas alcanza para enviar mensajes por Slack o responder correos,
  • Google Docs muchas veces no funciona bien
  • Al final, termina siendo una experiencia en la que uno se rinde
• En cambio, servicios como Instagram ofrecen una experiencia rápida de forma consistente

El efecto del software rápido

• La rapidez se siente mágica
• El software rápido elimina la fricción cognitiva y, como Raycast o Superhuman, responde un paso antes de lo que uno espera
• La latencia inferior a 100 ms de Superhuman y su excelente soporte para atajos revolucionan la experiencia de usar correo electrónico
• La función de transferencias instantáneas de Mercury también sorprende a usuarios acostumbrados a operaciones bancarias lentas
• La velocidad de estas herramientas no suele recibir elogios explícitos, pero es lo que hace que los usuarios las sientan casi como magia

Rapidez, simplicidad y enfoque

• La rapidez equivale a simplicidad y es un valor cada vez más escaso en el entorno moderno del software
• Para que un software sea rápido, hace falta eliminar funciones innecesarias
• Herramientas de gestión de proyectos minimalistas como Linear ofrecen una experiencia de uso muy superior en velocidad frente a aplicaciones empresariales como Workday u Oracle
• La rapidez es una forma de respeto hacia el usuario, porque demuestra que se filtró con rigor todo lo innecesario

El esfuerzo oculto para construir rapidez

• Para crear software rápido se necesita una optimización compleja del backend
• En Cash App, se esfuerzan por agregar solo los pasos imprescindibles en el recorrido del usuario, mientras la complejidad se resuelve internamente
• En Instagram, al subir una foto, la carga empieza al mismo tiempo que el usuario escribe el pie de foto, para que se sienta como si la subida hubiera comenzado de inmediato
• La rapidez no es solo un logro técnico, sino el resultado de prioridades claras y enfoque

La rapidez como diversión y motivación

• El software rápido por sí mismo genera diversión y satisfacción
• Incluso en detalles pequeños, como medir la velocidad de escritura (WPM) o configurar atajos, los usuarios disfrutan la experiencia de volverse más rápidos

La relatividad de la rapidez

• Los flujos de trabajo basados en AI y LLM ofrecen una experiencia muy superior en velocidad frente a los métodos tradicionales
• Por ejemplo, dedicar 6 minutos a encargarle una investigación a un LLM puede generar una productividad más de 10,000 veces mayor que antes
• Sin embargo, en los procesos de desarrollo, build y despliegue de apps de AI todavía hay muchas carencias frente a la era anterior del software
• En este momento, el foco sigue estando más en las nuevas funciones que en el rendimiento y la experiencia
• En el futuro llegará una tendencia a priorizar la optimización en aspectos como baja latencia, diseño de interfaces, conectividad y confiabilidad
• Y con eso se abrirán más posibilidades nuevas y una evolución de la experiencia de usuario

Material de referencia

• Como materiales adicionales útiles sobre la rapidez, están los siguientes textos
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Comentarios en Hacker News

• De verdad agradezco que YCom mantenga la interfaz de HN rápida y bien cuidada. Me pasó que dejé Slashdot en cuanto cambió por completo la interfaz con eso de una “UI moderna” y terminó convertido en algo con muchísimo espacio en blanco y una estructura difícil de escanear. Antes era un sitio que leía todos los días
  • La densidad de información y poder encontrar rápido lo que buscas es casi lo opuesto a eso de “engagement”. Muchas veces los sitios se vuelven complejos a propósito para inflar la métrica de tiempo en página y vender eso a los anunciantes. La página carga lento intencionalmente para hacerte dar clic por error y empujarte a la “conversión”. En la práctica, engañar a la gente suele dar más dinero que poner al usuario al centro
  • HN es el sitio que abro para comprobar si tengo conexión a internet. En medio de tanto bloat web, de verdad brilla
  • La UI de HN también necesita mejoras, sobre todo en móvil. El contraste es bajo, los botones son demasiado pequeños y cuesta usarlos, no hay modo oscuro, etc. Tengo una versión de lo que considero una UI ideal hecha en Elm, totalmente client-side, usando la API de Firebase de HN: https://seville.protostome.com/
  • No creo que Slashdot se haya venido abajo por la UI. Su valor real estaba en los comentarios de altísimo nivel que dejaban los SME al principio. Después de que vendieron el sitio, entre usuarios de menor nivel, mala administración y la fuga de gente, empezó la bajada. Hasta me sorprende que el sitio siga vivo
  • El orange site (HN) todavía no soporta etiquetas de enlace en Markdown
• Siento que los flujos de trabajo con LLM en la práctica muchas veces son más lentos. La función de “refactor” del IDE termina en 1 segundo, pero si se lo dejas a un asistente de IA tarda 30 segundos, y con el enfoque de “agente” se va a 15 minutos. Por ejemplo, le encargué a un agente código para un endpoint HTTP y al principio pensé “terminó en 10 minutos lo que era trabajo de un día”, pero al revisarlo vi que la lógica estaba enredada y el manejo de errores era flojo. Al final lo reescribí yo mismo durante unas 5 horas y quedó con mejores pruebas y un manejo de errores mejor del que habría hecho por mi cuenta. También hay estudios al respecto https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • Ya he escrito varias veces sobre este tema. Creo que, para una herramienta de programación, que los LLM persigan puntajes de benchmark va en la dirección equivocada. En mi experiencia se equivocan con una probabilidad bastante alta, así que siempre tengo que revisar el resultado; eso alarga el intercambio con el LLM, y como además responde lento, muchas veces siento que me convendría más hacerlo yo mismo a mano. Lo que yo querría es un agente que responda en menos de 1 segundo, aunque esté apenas al 60% en benchmarks
  • Donde sí me ha acelerado de verdad un LLM es en una especie de find/replace avanzado para código. Por ejemplo, si le pides que cambie en varios lugares la “lógica relacionada con XXX” por otra cosa, responde bastante bien. Me ahorra mucho trabajo de estar buscando y cambiando todo a mano. Eso sí, no lo he probado en código gigantesco
  • Creo que depende del caso. Para refactors, si el IDE o el language server lo soportan, es muchísimo más rápido; para otras cosas, el LLM sí ayuda. Por ejemplo, ayer hice la lógica de normalización de URL como MVP, y como en los datos del cliente había URLs de muchas formas distintas, había muchos casos de validación. Le pasé a Claude los casos más comunes del cliente y le pedí que generara “casos de prueba de mínima cobertura”; en 5 a 10 segundos me dio el resultado, y con eso usé la función de agente Opus en Zed para crear el archivo de pruebas. Luego revisé los casos, limpié lo innecesario y mejoré algo de la lógica. Ese método fue mucho más rápido que hacer todo yo solo
  • Estoy oyendo mucho, en línea y fuera de línea, que en trabajo senior la velocidad mejora entre 40% y 60%. Aun así, no da la impresión de que ya estemos en un punto donde puedas confiar solo en agentes de IA y desentenderte de todo
• Esta es una anécdota de cuando, siendo junior, me gané fama como ingeniero de software por mejorar velocidad. Era una época en la que importaban tanto el conocimiento de algoritmos como la capacidad de leer la salida del compilador, y en la que Carmak y Abrash se estaban volviendo estrellas. A los 22 años participé por primera vez en una reunión con un gran cliente multinacional, y nos señalaron que la velocidad de nuestro producto era un problema. Escuchar al VP de esa empresa decir directamente que “1 segundo más rápido equivale a 1 millón de dólares extra de ganancia anual” me dejó totalmente impactado. Fue el momento decisivo en que vi por primera vez la velocidad traducida a dinero de esa manera. Incluso 20 años después, sigue siendo uno de los momentos más memorables de mi carrera. Y otro ingeniero además le bromeó al VP con “entonces, si lo bajamos a 0 segundos, ¿ganan dinero infinito?”. En esa sala nadie se rió, pero a mí sí me pareció bastante gracioso
  • ¿No sería que pasar de 1 segundo a 0, o de 2 a 1, suma 1 millón cada vez? La lógica de que eso llevaría a dinero infinito sí está medio rara
  • Me da curiosidad si al final sí lograron hacerlo más rápido
• Reacciono porque conecté con la primera frase del post. Los usuarios no suelen decirle directamente a los desarrolladores “háganlo rápido”, pero si no lo es, tampoco confían en ello. Si Rust fuera más lento que Ruby, a nadie le importaría. Rust llama la atención porque puede decir “soy más rápido que C++”. En HN también, basta con que algo sea “rápido” para que todos se emocionen. Si es aunque sea un poco más rápido, enseguida recibe atención
  • Eso solo aplica a la pequeña capa de programadores que escribe en HN. A la mayoría de los desarrolladores y a los usuarios comunes no les importa mucho que algo sea lento, mientras la UI sea cómoda. Incluso muchos data scientists profesionales usan bastante Github Desktop en vez de comandos ultrarrápidos
  • Creo que la conclusión es incorrecta. “Rápido” es un diferenciador muy fuerte cuando ofrece el mismo conjunto de funciones más deprisa. La gente se mueve hacia “X más rápido que X”, pero también puede moverse por más funciones, mejor UX, menor precio o una oferta mejor, y aun si algo es lento, sigue siendo una opción elegible
  • En lenguajes y runtimes la velocidad importa, pero cuando usas frameworks pesan más otros factores como características o compatibilidad. La gente usa muchísimo Electron aunque sea lento
  • En la práctica vivimos en un mundo donde una gran parte de las apps, sobre todo web, son absurdamente lentas. Es de lo más común que haces algo y pasan varios segundos antes de que llegue la respuesta. Aunque digamos que “lo rápido es lo mejor”, la realidad es la contraria
  • A los usuarios de HN les gusta la “rapidez” porque sabemos que la mayoría de la tecnología con la que convivimos hoy es demasiado lenta, y que en esencia podría hacerse mucho más rápida
• Por otro lado, si algo es “demasiado” rápido, también pasa que la gente duda si realmente funcionó. En el caso de TurboTax, el análisis real tomaba menos de 1 segundo, pero al poner a propósito una pantalla de carga falsa, la gente lo confiaba más y le gustaba más. Aunque el procesamiento real fuera mucho más corto, hicieron que pareciera lento para transmitir la confianza de que “de verdad lo revisó”
• La rapidez también importa desde el costo. En la nube, donde pagas por segundo, si no optimizas todo el proceso es imposible ofrecer un servicio de transcripción barato a nivel empresa. Por ejemplo, la imagen que hice quedó 2.5 veces más pequeña que la de un proyecto open source, y eso llevó a arranques en frío más rápidos, menor costo y mejor servicio https://speechischeap.com
  • ¿S3 es lento o rápido? En realidad, ambas. Si lo ves como una sola request es lento, pero si lanzas muchas en paralelo, se siente rápido. Al final, “rápido” a veces es clave para sobrevivir y a veces es una estética
  • Yo hago lo contrario: corro el servicio en hardware de consumo y opero mucho más barato que en la nube. No necesito preocuparme por el tamaño de la imagen (bare metal es más rápido). Incluso doy gratis transcripción de 20 mil minutos por minuto, con un límite de 5 segundos por request. También estoy desarrollando alternativas open source y multiplataforma relacionadas https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer Si a alguien le interesa innovar en servicios de transcripción, feliz de que me contacte
  • Espero que herramientas como PAPER, al menos en Linux, logren mantenerse por debajo de 2 MB de tamaño total de instalación, incluso contando caché. pip pesa 10 a 15 MB, pipx más que eso, y uv 35 MB. Estoy intentando llegar a algo más pequeño
  • Que algo sea rápido no significa necesariamente que sea ligero y eficiente. Muchas veces se vuelve rápido simplemente metiéndole un montón de hardware caro
• Siempre tengo que recordármelo cuando veo artículos que se quejan de las transferencias bancarias en Estados Unidos. En Reino Unido o Suiza, por ejemplo, una transferencia bancaria casi se completa al instante. Me pregunto por qué en EE. UU. es tan lento
  • Los bancos regionales de EE. UU. casi no tienen programadores propios y dependen de “core processors”. Por eso las actualizaciones del sistema avanzan lentísimo. Implementar Faster ACH tomó años, y el lobby de bancos regionales pidió retrasarlo porque les perjudicaba. Recomiendo este blog, que lo explica muy bien https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • Lo que vuelve lento a ACH es la programación de horarios y el procesamiento por lotes. La transferencia en sí puede terminar de inmediato, pero normalmente se agrupa y procesa cerca de la medianoche. Por eso Venmo y Zelle son populares en EE. UU. En Suiza también las transferencias IBAN son lentas, y los pagos en tiempo real los domina TWINT, con QR. En Reino Unido, BACS también es lento por la misma razón
  • En EE. UU. sí existen dos sistemas de transferencias en tiempo real: RTP y FedNow. Cada vez se suman más bancos participantes https://real-timepayments.com/Banks-Real-Time-Payments.html. Antes también se podían hacer envíos instantáneos pagando una pequeña comisión a través de redes de tarjeta de crédito. Eso sí, las tarjetas de crédito tienen reglas de garantía y reembolso distintas, y en caso de fraude la pérdida para el banco es mayor
  • Esto también puede ser mejor para el consumidor. Por ejemplo, cuando intentan sacar dinero por débito automático de una cuenta sin saldo, el banco te manda varios correos de aviso. Si todo fuera realmente instantáneo, el problema ya habría pasado; en cambio, hoy te da tiempo de recibir la notificación y actuar por tu cuenta, evitando cargos por mora o comisiones. Como no es una transferencia inmediata, el banco puede avisarte y tú todavía tienes margen para reaccionar
  • patio11 escribió bastante a fondo sobre esto https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• El artículo me pareció interesante y deja bastante para pensar. Cuando la velocidad se siente de verdad, importa menos el throughput real que la “rapidez percibida”, o sea, cosas como la respuesta de la UI o el input lag, esa sensación de fluidez. Por eso terminé prefiriendo Go sobre Rust. Go compila lo bastante rápido como para sentirse casi imposible de medir. En cambio, cuando algo es lento, aunque el throughput real sea bueno, simplemente me cae mal igual (como los startups de Java)
  • Incluso comparando Go y Rust, la velocidad de compilación se siente realmente importante. Los builds de Rust tienen muchas dependencias y terminan haciendo que la estructura del proyecto se parezca a la de JavaScript. Go, en comparación, tiene muchas menos deps, y eso me gusta
  • Está bien que los desarrolladores discutan estas cosas, pero lo que de verdad importa es “qué lenguaje es más rápido para el usuario”
• A diferencia de eso de que “casi nunca se oye ‘háganlo rápido’ en software”, en casi todas las empresas donde trabajé la prioridad máxima era la velocidad de respuesta de la página y la latencia. Fuera startup o gran empresa, velocidad y latencia eran objetivos importantes, y casi siempre se consideraba crucial qué tan rápido se sentía el producto, qué tan rápido cargaba la página y si había retrasos raros
  • En la mayoría de las empresas que viví personalmente (6 de 8), casi nunca daban tiempo para optimizar rendimiento, así que siempre lo hacía a escondidas. Incluso en las que medían latencia y decían que era importante, al final se iba quedando atrás frente a agregar nuevas funciones
  • Muchas veces se obsesionaban con mejorar la velocidad de los resultados de búsqueda, pero no prestaban demasiada atención al renderizado de la página ni al tamaño de los datos enviados al usuario
• Es algo que he visto repetirse en varios trabajos: la mayoría subestima el verdadero valor de la velocidad. Asumen simplemente “hacer el mismo flujo más rápido”. Por ejemplo, piensan que acelerar un experimento grande que corre toda la noche no ayuda tanto; pero si elevas muchísimo la velocidad, ya puedes correr varios experimentos durante el día, y eso cambia la productividad a otro nivel
  • La gente subestima muchísimo el costo del cambio de contexto. Reducir un comando de 30 segundos a 3 parece apenas ahorrar 5 minutos al día si lo haces 10 veces, pero en realidad el costo de la interrupción es mucho mayor
  • Cada vez que una pipeline de CI tarda horas, pienso que si terminara en 20 minutos, corregiría incluso los warnings menores de lint en ese mismo momento