A los usuarios no les importa, pero a ti sí debería importarte
(lewiscampbell.tech)- Los usuarios priorizan que el producto funcione más que las propiedades intrínsecas del código en sí, pero el mal código tiene efectos secundarios directos sobre el rendimiento, los errores y la velocidad de desarrollo
- Decir que “a los usuarios no les importa el stack tecnológico ni las pruebas” es superficialmente cierto, pero cuanto peor es la calidad del código, más difícil y lento se vuelve corregir errores y agregar funciones
- Igual que en las analogías de la inspección de puentes, un piloto ebrio o los cimientos inestables de un edificio, aunque el usuario no vea el proceso en sí, el resultado sí afecta la seguridad y la confianza
- Detrás de la popularidad de esta idea podría operar un mecanismo de defensa del ego que lleva a devaluar aquello en lo que uno no es bueno
- El trabajo serio de software es una mezcla de distintas preocupaciones y perspectivas, y todas contribuyen al éxito o al fracaso, por lo que no se debe tomar a la ligera la calidad del código
El cliché repetido y sus límites
- En la industria del software se repiten frases como
- “A los clientes no les importan las pruebas; solo les importa que el producto funcione”
- “A los usuarios no les importa el stack tecnológico”
- “La elegancia de ingeniería no es lo mismo que el valor de mercado”
- “A los usuarios no les importa si lo escribió una IA o una persona, ni qué framework se usó; solo les importa que el producto funcione”
- Todas estas frases son variaciones sobre el mismo tema: “a los clientes no les importa eso”
- Adoptan una actitud como si un pragmático curtido estuviera revelándoles la dura realidad del mundo a personas idealistas o de miras cortas
- Pero todo esto es pura tontería (horseshit), y al aplicar la misma lógica a otros campos, quedan expuestos sus vacíos
- A los usuarios de la carretera no les importa si un puente pasó la inspección final; solo les importa que sostenga su auto
- A los pasajeros no les importa si el piloto está borracho; solo les importa que el vuelo llegue a tiempo
- A los oficinistas no les importa si los cimientos de un rascacielos son estables; solo les importa ganar dinero
- Estas analogías son superficialmente correctas, pero ignoran efectos secundarios evidentes
Efectos secundarios ignorados
- Es cierto que a los clientes no les interesan las propiedades intrínsecas del código, pero la calidad del código sí afecta el rendimiento, la presencia de errores, el tiempo para corregirlos y el tiempo para agregar funciones
- Cuanto peor es el código, más difícil y más lento se vuelve resolver estos problemas
- Empresas como AirBnB, OpenAI y Meta pueden forzar estas preocupaciones gracias a su enorme poder de mercado, su gigantesco respaldo de VC y una legalidad cuestionable
pero, si no eres una empresa así, es difícil tapar los problemas de la misma manera
La persistencia de la “sabiduría popular” y las múltiples preocupaciones del software
-
La persistencia de la sabiduría popular (The Persistence of Folk Wisdom)
- La idea de que solo importan los efectos de primer orden se ha asentado en el software como una sabiduría popular muy extendida
- La gente tiende a descontar o minimizar aquello en lo que no es buena
- Si alguien percibe que no tiene la capacidad de escribir buen código, le resulta fácil adoptar la postura de que el buen código no solo no importa, sino que las personas capaces de producirlo son, de hecho, el problema
- Desde esa perspectiva, se trata como problemáticas a las personas que frenan un lanzamiento por cosas que al cliente no le importan
- Esta actitud funciona como un mecanismo de defensa del ego que evita las propias debilidades y traslada la responsabilidad a otros
-
Vivimos en sociedad (We Live in a Society)
- El trabajo serio de software es una mezcla de preocupaciones distintas y perspectivas diferentes
- Desde las ventas técnicas (
tech sales) hasta el stack tecnológico (tech stack), y desde la experiencia de usuario (UX) hasta los identificadores únicos (unique identifiers), muchos elementos forman parte del esfuerzo de software - Todos esos elementos contribuyen al éxito o al fracaso
1 comentarios
Comentarios en Lobste.rs
Este tipo de frases pueden ser buenas o malas tanto en cómo se transmiten como en cómo se leen
Por ejemplo, la frase “al cliente no le importan en absoluto las pruebas; le importa que el producto funcione” no significa “publica con bugs”, sino que puede leerse como una invitación a enfocarse en que el producto realmente funcione más que en una ideología de testing específica
Como las pruebas son solo uno de los medios para hacer que el código funcione, si tienes alta cobertura y todo pasa pero el producto no funciona, eso es un fracaso; y si logras que el producto funcione bien por otros medios que no sean las pruebas, también está bien; incluso si no sigues una doctrina formal pero detectas bien los bugs, también puede interpretarse así
Además, desde la perspectiva del usuario y del negocio, que un producto o función no exista también puede ser un bug, así que corregir bugs existentes y lanzar funciones no siempre están claramente separados
Pero en la práctica también he oído que este tipo de frases se usan con el sentido de “haz trampa y lanza basura”
Rechazo por completo la idea de que una programación horrible sea “práctica”, incluso si la miras en plazos de varios meses
Crear funciones nuevas en una base de código con mal diseño y pocas pruebas es lento y caro
Los desarrolladores deben ser conscientes de si están dedicando su tiempo a donde se genera valor, e idealmente la gerencia también debería entender por qué se hacen esas cosas
Cuando se combinan la falta de entendimiento y una estructura de incentivos equivocada, al final terminas “haciendo trampa y lanzando basura”
Sinceramente, muchas veces la gente que dice esto también parece gente a la que los usuarios tampoco le importan mucho
Para que el usuario reciba un producto que funcione, el proceso de desarrollo debe incluir mecanismos que aumenten esa probabilidad; eso ya lo comenté en un comentario de hace unos días
Este tipo de actitud aparece seguido cuando los usuarios no tienen una forma real de dar retroalimentación sobre el producto y tampoco existen métricas reales de uso
Hay muchos escenarios de falla que afectan al usuario aunque no los vea de inmediato ni les preste atención
Un ejemplo claro es la seguridad: al usuario puede no importarle que algo “no sea seguro” hasta que sus datos aparezcan en una filtración en línea; y con el rendimiento pasa algo parecido, porque tal vez no lo perciba como problema hasta que descubre que podría ser mucho mejor
En cualquier proceso de mejora es difícil obtener buenos resultados optimizando un solo elemento aislado, pero para lograr avances en una discusión muchas veces no queda más que hacerlo así
Por eso ayuda ir ajustando la conversación alineando la ruta de retroalimentación con dónde están realmente los problemas visibles
Veo este tipo de textos como un intento de hacer pensar en elementos que influyen en el éxito de un proyecto de software aunque parezcan excluyentes entre sí
Tiene valor poner en palabras y defender cosas que solo entienden quienes tienen criterio técnico, pero da la impresión de que muchos técnicos no logran equilibrar bien ese trabajo invisible ni convencer de forma efectiva, y yo también sigo practicando esa parte
Importarse por lo interno es importante y, de hecho, también beneficia al usuario
Me gusta esta perspectiva
No quiero irme al extremo opuesto del sobreingeniería, pero sí me gustaría dejar atrás la mentalidad de “muévete rápido y rompe cosas”
Por experiencia, en el mundo del desarrollo web esto parece casi una epidemia
Ojalá que la avalancha de software de baja calidad que hicieron posible los LLM termine haciendo que los usuarios recompensen más el software confiable
Cada vez me convierto más en un desarrollador de grug brain, así que no sé si esto es una sensación muy compartida, pero ya me cansé del “agreguemos una función más”
Muy seguido cometemos el error de medir el costo del software solo por la fecha de lanzamiento, y casi no incluimos los costos de mantenimiento que aparecerán durante toda su vida útil
Dicen “no es difícil, toma menos de una semana”, pero no mencionan las 2 a 4 semanas por año que se irán en mantenimiento, correcciones, extensiones, actualizaciones, integración y documentación
Suelo decir algo parecido
“Al usuario final no le importa si el software tiene 100% de cobertura de pruebas o si está escrito al 100% en ensamblador sin documentación con etiquetas como
lbl0; le importan la exactitud, el rendimiento y la experiencia de usuario”Pero la ingeniería de software precisamente ayuda a alcanzar más fácilmente esos objetivos y a mantener la calidad en un buen nivel
El problema es que este camino también puede llevar al culto de carga y a la sobreingeniería, y sin duda yo también he pecado de eso
Aun así, al final hay que entregar valor real al usuario
Como con Boeing y Airbus, existe un resultado óptimo demostrable
Lo importante no es por qué los aviones de ambas compañías se ven tan parecidos, ni quién diseñó primero ni quién le copió a quién
Nadie copió: simplemente los mejores ingenieros del mundo, trabajando en equipos distintos bajo las mismas restricciones, terminan produciendo diseños donde cualquier desviación resulta inferior por definición
Tienes que estar en la frontera de Pareto, y si no, te devoran
En nuestro campo también existe algún punto óptimo; la cuestión es si tienes las herramientas, el presupuesto y la gente adecuada para llegar ahí, y si tienes suficientes usuarios como para saber si de verdad llegaste