- La función esencial del software está en saber con claridad qué problema debe resolver y reconocer sus límites
- El buen software no intenta abarcar todas las funciones, sino que solo aborda las partes que necesitan mejoras y no se desvía de su propósito
- Se presenta un caso hipotético en el que el comando
ls es reemplazado por funciones de IA, satirizando el fenómeno de la expansión innecesaria de herramientas existentes
- Citando los principios expuestos en ‘Getting Real’ y ‘Rework’ de 37Signals, se enfatiza que hay que convertir las limitaciones en ventajas y rechazar solicitudes de funciones innecesarias
- Incluso en medio del furor por la IA, se recuerda que la estabilidad de los estándares existentes y una definición clara del problema tienen más valor que las nuevas modas
El papel y los límites del software
- El texto comienza con una escena imaginaria en la que, tras actualizar una distribución de Linux, el comando
ls cambia a una inteligencia de directorios basada en IA
- El nuevo comando
als predice la intención del usuario, clasifica los archivos por relevancia y muestra un mensaje indicando que el ls actual dejará de tener soporte en 30 días
- Esta escena es un ejemplo satírico de sobrecarga de funciones e innovación innecesaria
- “Por suerte, esto no ocurre en la realidad”, y se subraya que el buen software sabe cuándo debe detenerse
Principios clave del buen software
- El buen software sabe qué propósito cumple, no intenta hacerlo todo y distingue entre cuándo detenerse y qué debe mejorar
- La ‘mentalidad maximalista’ humana tiende a hacer que todo sea más grande y más complejo
- Sin embargo, el software debe definir con claridad su papel y su lugar, y si una idea nueva no encaja con la visión existente, debe separarse en un proyecto distinto
La filosofía de producto de 37Signals
- ‘Rework’ y ‘Getting Real’, escritos por los fundadores de Basecamp, ofrecen lecciones importantes para el diseño de productos
- Las limitaciones son ventajas (Constraints are advantages): equipos pequeños, presupuestos limitados y alcances reducidos llevan a tomar mejores decisiones
- Ignorar solicitudes de funciones (Ignore feature requests): más que implementar tal cual lo que pide el usuario, hace falta entender el problema de fondo
- Lanzar pronto y lanzar seguido (Ship early, ship often): un producto imperfecto pero que realmente funciona vale más que uno perfecto que nunca se lanza
- Diseño desde el epicentro (Epicenter design): antes que la navegación o los elementos periféricos, hay que diseñar primero la interfaz central y las interacciones clave
- Decir “no” por defecto (Say no by default): las nuevas funciones traen costos ocultos como más complejidad, mayor costo de mantenimiento y más casos excepcionales
- Crear lo que tú mismo necesitas (Scratch your own itch): un producto que resuelve un problema que realmente necesitas resolver permite tomar mejores decisiones
El valor de perdurar más que cambiar
- Últimamente, varios productos siguen la tendencia de reconfigurar su nombre y sus funciones alrededor de la IA
- MinIO → AIStor
- Oracle Database → Oracle AI Database
- No todo necesita cambiar de forma dramática
- En un área problemática específica, convertirse en un estándar de facto (de facto standard) tiene un valor mayor
1 comentarios
Comentarios de Hacker News
Al ver el consejo de “ignora las solicitudes de funciones”, pensé en el caso de Blizzard y World of Warcraft Classic
Durante años los usuarios pidieron una versión clásica, pero Blizzard se negó diciendo “eso no es lo que quieren”
Al final lanzaron Classic WoW y fue un éxito abrumador
Más tarde, el equipo de desarrollo reconoció que “los usuarios realmente sí sabían lo que querían”
Es decir, más que ignorar siempre las solicitudes de funciones, hay que admitir que a veces el usuario puede tener exactamente la razón
En cambio, con un usuario grosero o egocéntrico, la conversación en sí se vuelve agotadora y uno deja de responder
Al final, la lección es que hay que pedir las cosas con cortesía
Después de eso, hay que decidir si es una petición válida y pensar cómo implementarla
El problema de fondo era un “juego que había perdido su sensación original”, y si se hubiera entendido eso, también se podría haber resuelto de otra manera sin recurrir a Classic
WoW Classic era la expresión de un deseo superficial de recuperar la “sensación de antes”, pero debajo había desconfianza hacia una dirección de desarrollo poco confiable
En un mundo ideal sería posible una forma perfecta que mezclara lo mejor de ambas versiones, pero en la realidad los choques de opinión solo aumentarían la confusión
Añadieron instancias no PVP siguiendo las peticiones de los usuarios, y al hacerlo desapareció la tensión, haciendo que el juego se volviera insípido
En este caso, los desarrolladores sí entendían mejor que los usuarios
Creo que debería haber más software terminado que deje de agregar funciones
Hace falta el valor de decir “con esto basta”
Hay muchos casos como Evernote o Dropbox, que después de una etapa en la que eran perfectos se volvieron confusos por el exceso de funciones
Se vendía en caja, y cuando salía una nueva versión había que comprar otra caja
Era la época anterior a las webapps con actualizaciones constantes como las de hoy
De hecho, muchas veces empeora cuanto más se actualiza
Los productos que de verdad mejoran son muy pocos
Al final volvió a crear el mismo problema que originalmente pretendía resolver
Pero con el tiempo dejó de ser compatible con nuevas versiones de iOS y al final ya no se pudo usar
Ahí se siente a la vez la belleza de lo terminado y la crueldad de la evolución tecnológica
Cuando en 2020 pasé de infraestructura a ser desarrollador Java, vi que muchas bibliotecas principales estaban en modo de mantenimiento y pensé “¿Java está muerto?”
Pero después entendí que en realidad eso significaba que estaban completas en funciones
Era un estado estable donde ya se habían resuelto muchísimos casos límite
El problema es que la gente no quiere esa estabilidad, sino siempre algo nuevo
Al final se vuelve a construir el mismo framework una y otra vez, solo cambiando el lenguaje
Por eso prefieren proyectos que siguen en desarrollo
Además, algunas empresas solo pueden usar software que siga recibiendo actualizaciones por requisitos de compliance
Bromeé diciendo “simplemente ya está terminada y no queda nada por mejorar”, pero igual la cambié
Me gusta Sublime Text por su simplicidad y su velocidad
No le mete IA ni funciones complicadas, y se enfoca en un solo propósito
El buen software no necesariamente es el software que gana dinero
Pero para ganar dinero hacen falta funciones que la gente realmente use
Como cada usuario usa un 20% distinto de funciones, hay que considerar esa diversidad
Pensaba que Notepad.exe era un caso representativo de software terminado,
pero me sorprendió que en Windows 11 haga falta una maniobra casi de hacking para cambiar la asociación de archivos
Si ves el blog de Windows Insider y el aviso de seguridad,
dicen que el problema son justamente las actualizaciones que nunca saben detenerse
Reconozco la belleza del software terminado, pero hoy casi todo está en estado de “beta eterna”
Como se da por hecho que hay conexión a internet, apareció una estructura donde “siempre se puede actualizar”,
y no existe separación entre corregir errores y añadir funciones no deseadas
En servicios web como YouTube ni siquiera se puede elegir la versión
Sobre todo con la incorporación de Canvas, su filosofía original de simplicidad empezó a tambalearse
Si hubiera sido open source, quizá la habría forkeado en ese momento
Signal es gratis, open source y centrado en la privacidad, así que tiene pocas funciones
Pero precisamente eso es lo que me gusta
WhatsApp solo sigue acumulando funciones innecesarias
Antes no entendía la importancia de lo “siempre necesario” (evergreen) de la que habla 37signals en sus libros, en especial la velocidad
Pero con el tiempo, al ver cómo las apps se vuelven cada vez más lentas, me di cuenta de lo enorme que es el valor del software rápido
Me recuerda la frase de 『REAMDE』 de Neal Stephenson: “a los escritores les gustan las residencias”
Así como los escritores siguen generándose trabajo para mantener esas residencias, los desarrolladores también tienden a cambiar código para fabricarse trabajo
Al final, nosotros también repetimos cambios por el simple hecho de cambiar