Al usuario no le importa — pero a ti sí debería importarte
(lewiscampbell.tech)- Al usuario le importa más que el producto funcione que las propiedades intrínsecas del código en sí, pero el mal código impacta directamente de forma secundaria en el rendimiento, los bugs y la velocidad de desarrollo
- Decir que “al usuario no le 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 bugs 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 afecta la seguridad y la confianza
- Empresas como AirBnB, OpenAI y Meta pueden forzar este tipo de problemas gracias a su dominio del mercado, enorme respaldo de VC y legalidad cuestionable, pero no todas las empresas están en esa posición
- El éxito del software es el resultado de la interacción de múltiples intereses y perspectivas, desde ventas técnicas, stack tecnológico y experiencia de usuario hasta identificadores únicos
Clichés repetidos y sus límites
- En la industria del software se repiten frases como “a los clientes no les importan las pruebas, solo que el producto funcione”, “a los usuarios no les importa el stack tecnológico”, “la elegancia de ingeniería no equivale al valor de mercado” o “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 variantes del mismo tema: “al cliente no le importa eso”, y se presentan como un pragmatismo que dice una realidad fría
- Si aplicas la misma lógica a otros campos, se hace evidente lo superficial del problema
- Decir que a quienes usan una carretera no les importa la inspección final del puente, solo que soporte el peso del auto
- Decir que a los pasajeros no les importa si el piloto está borracho, solo que el avión llegue a tiempo
- Decir que a los trabajadores de oficina no les importa la estabilidad de los cimientos de un edificio alto, solo ganar dinero
- Estas analogías son correctas en la superficie, pero ignoran efectos secundarios evidentes
- Es cierto que a los clientes no les interesan las propiedades intrínsecas del código, pero la calidad del código afecta el rendimiento, la presencia de bugs, el tiempo para corregirlos y el tiempo para agregar funciones
- Cuanto peor es el código, más difícil y más lento resulta resolver estos problemas
- Se señala que empresas como AirBnB, OpenAI y Meta pueden empujar estas preocupaciones a un lado gracias a un enorme dominio del mercado, gran respaldo de VC y una legalidad cuestionable
- La conclusión es que, si tu empresa no es una de esas, será difícil tapar los problemas de la misma manera
La persistencia de la ‘sabiduría popular’ y los múltiples intereses del software
-
La persistencia de la sabiduría popular
- La idea de que solo importan los efectos de primer orden existe en el software como una creencia 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 producir buen código, le resulta fácil adoptar la postura de que el buen código no solo no importa, sino que quienes sí pueden producirlo son el verdadero problema
- Desde esa perspectiva, las personas que frenan lanzamientos por cosas que al cliente no le importan son tratadas como el problema
- Esta actitud funciona como un mecanismo de defensa del ego para evitar las propias debilidades y externalizar la responsabilidad hacia otros
-
Vivimos en sociedad
- El trabajo serio de software es una mezcla de intereses distintos y perspectivas diferentes
- Desde ventas técnicas hasta el stack tecnológico, y desde la experiencia de usuario hasta los identificadores únicos, 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