Mi estrella del norte del software
(kristoff.it)Prioridades al desarrollar software
- El software debe ser útil para el usuario final y aspirar a convertirse en "software que puedas amar"
- El software debe ser correcto (correct). Un software que funciona mal reduce la utilidad que el usuario puede obtener
- El software debe ser mantenible y eficiente. Es un criterio para evitar desperdiciar recursos humanos y de cómputo cuando se intenta extraer más utilidad del software
Lo absurdo de cuando se invierten las prioridades
- Aunque una blockchain no tenga bugs, no significa nada si es un rugpull
- Aunque el lenguaje que uses sea memory-safe, no significa nada si no existe un diseño orientado a la corrección ni un proceso para ir corrigiendo todos los bugs al final
- Aunque el software tenga una hermosa capa de abstracciones (canopy of abstractions), no significa nada si funciona pésimo y nadie puede darle mantenimiento ni agregar nuevas funciones
A veces me desanimo, a veces tomo el camino equivocado y a veces doy rodeos a propósito, pero nadie puede hacer que confunda mi verdadero destino con algo inferior.
Valoro mi experiencia como desarrollador, pero la valoro solo en la medida en que me ayuda a crear más software que otras personas y ustedes puedan disfrutar.
- El objetivo final es maximizar la utilidad para el usuario final, y todo lo demás es un medio para alcanzar ese objetivo
- Este es el principio más importante al desarrollar software
1 comentarios
Comentarios en Lobste.rs
Prefiero un enfoque parecido
Incluso herramientas no tan “adorables” como un destornillador pueden ser muy confiables durante muchísimo tiempo. Un destornillador Phillips siempre tiene punta Phillips, y cuando lo sacas de la caja de herramientas no hay un 1% de probabilidad de que se haya convertido en uno plano y tengas que guardarlo y sacarlo otra vez. Tampoco cambian el diseño del mango interminablemente, y puedes simplemente usar la herramienta que compraste hasta que se rompa
Ojalá más software fuera así
Respeto y agradezco a los desarrolladores que se apegan al criterio de que “el objetivo final es maximizar la utilidad para el usuario final, y todo lo demás está al servicio de ese objetivo”, pero yo mismo no siempre vivo así. Creo que el software tiene responsabilidades legítimas ante otros además del usuario final
Profesionalmente, hago software para mantener a mi familia, y aunque suelo ponerme bastante del lado del usuario, al final mi lealtad es mayor hacia la empresa que paga y hacia mi familia.
En el trabajo personal, el criterio es “¿esto me resulta satisfactorio a mí?”, y la satisfacción artística, estética e intelectual es importante. Por lo general coincide con el beneficio del usuario, pero también puedo juzgar mal cuál es la utilidad para el usuario, y por ejemplo, incluso si se demostrara que un menú hamburguesa animado maximiza la utilidad, creo que en mi obra puedo ejercer mi derecho de elección estética y renunciar a esa utilidad
También está el caso de cómo considerar situaciones donde a propósito se hace que parte del software sea poco amable con el usuario para impedir que ese usuario haga barbaridades que perjudiquen a los usuarios de su propio trabajo.
He llegado a discutir mecanismos así para mantener para siempre en estado de “todavía no” cierta función de reportes, muy vulnerable a la ley de Goodhart y con un alcance de efectos secundarios muy grande, aunque el usuario del software la quisiera
No fue hasta ver este texto que me enteré de que Tiger Style ya tiene sitio web
Se habla al mismo tiempo de “nadie puede darle mantenimiento, ni hablar de agregar funciones nuevas” y de “corregir todos los bugs”, pero la verdad no entiendo bien cómo sería posible arreglar todos los bugs sin al final congelar el alcance
La frase “aunque la blockchain no tenga bugs, si es un rug pull no sirve de nada” permite meter tres cosas en una sola oración
Mejorar la eficiencia de algo no sirve de nada si introduces nuevos bugs, y además solo sirve de algo cuando tampoco es un rug pull
Me llama la atención que no haya un requisito de que el software necesariamente tenga que ser escrito solo por humanos. Lo hace todavía más interesante porque entiendo que Kristoff es desarrollador principal de Ziglang
Quiero pensar que incluso usando desarrollo asistido por IA se puede hacer software que cumpla con este requisito.
Disfruto escribir código directamente a mano, y también disfruto terminar las cosas, pero a veces ambas cosas chocan.
Perdón por sacar el tema de la IA, pero es difícil separarlo por la relación cercana entre Kristoff y la comunidad de Zig, la postura fuerte de Zig, y el hecho de que de todos modos yo sigo evangelizando Ziglang
Que un proyecto tenga una postura clara sobre el código basado en grandes modelos de lenguaje no significa que todas las personas de ese proyecto compartan la misma postura sobre este proyecto o sobre todos los proyectos.
No es algo que aplique solo a Loris personalmente; en este tipo de decisiones, juzgar caso por caso es lo razonable