El botón de descargar que miente sobre su filtro

Si tu herramienta tiene una lista con filtros y un botón de descargar, esta nota describe un fallo que no da error, que produce resultados creíbles y que nadie detecta nunca. Y cómo se hace imposible.

Filtras tu lista de contactos: los que están esperando respuesta, de un canal, de este mes. Salen 84. Le das a descargar.

El archivo trae 91.

Nadie lo nota. Porque 91 contactos son una lista de contactos perfectamente plausible: los nombres son reales, los teléfonos son reales, todo parece bien. Nadie cuenta las filas de un archivo para compararlas con un número que vio en la pantalla hace diez segundos.

Un botón de descarga que miente sobre su propio filtro es peor que no tenerlo.

Nadie escribe dos filtros distintos a propósito. Divergen con el tiempo, y siempre igual.

El primer día se escriben iguales, copiando uno del otro. Funcionan. Seis meses después hay que corregir algo —«esperando» debería excluir los archivados, digamos— y se corrige donde se vio el problema, que es la pantalla.

La descarga se queda como estaba. Y no hay ninguna señal: no falla, no avisa, no aparece en ninguna prueba. Solo entrega otra cosa.

Lo que hace este fallo especialmente traicionero es que las dos respuestas son válidas por separado. No hay forma de mirar el archivo y decir «esto está mal». Solo está mal en relación a lo que decía la pantalla.

La solución obvia sería que la pantalla y la descarga usaran la misma consulta. Y es demasiado: hace daño por otro lado.

Porque lo que se pide sí es distinto. La pantalla pinta cuatro columnas. La descarga se lleva todo lo exportable. Forzarlas a compartir la consulta entera obligaría a la pantalla a traerse datos que no pinta, en cada carga, para nada.

Así que se comparte exactamente la parte que tiene que ser idéntica: la condición y sus valores. Lo que se selecciona, cada uno el suyo.

Esa es la operación general cuando dos caminos deben coincidir en parte: no unifiques los dos caminos, extrae la parte que tiene que ser la misma. Unificar de más produce el problema contrario, que es que uno de los dos arrastre lo que necesita el otro.

Esta forma —dos caminos que deben coincidir en qué filas— aparece más veces de lo que parece, y siempre con el mismo síntoma: números plausibles que no cuadran.

• El recuento antes de mandar y a quién le llega. Dices que van 340 y salen 352.
• Una lista y su paginación. La primera página usa una condición y el total usa otra, así que hay una página final vacía.
• Un informe y el detalle que lo compone. El resumen dice una cosa y sumar las filas da otra.
• Una notificación y la pantalla que abre. «Tienes 3 pendientes» y al entrar hay 5.

En los cuatro, el remedio es el mismo y el criterio para detectarlo también: busca los sitios donde el sistema dice un número y después entrega una lista. Cada uno de esos pares es un filtro escrito dos veces esperando a divergir.

Un apunte de diseño que reduce el problema antes de resolverlo.

Sobre una lista de contactos se pueden ofrecer veinte filtros. Nuestra lista ofrece pocos, y uno destaca: «esperando», o sea, a quién le debemos respuesta.

Es la única pregunta que se hace de verdad sobre esa lista todos los días. Los demás filtros existen porque a veces hacen falta; ese existe porque es el trabajo.

Y cuantos menos filtros haya, menos superficie hay donde dos caminos puedan discrepar. La forma más barata de que dos condiciones no divergan es que haya pocas condiciones.

• Filtra, cuenta lo que ves y descarga. Compara los dos números. Es una prueba de un minuto que casi nadie ha hecho nunca.
• Busca los pares «número y lista». Cada uno es un filtro escrito dos veces.
• Comparte la condición, no la consulta. Unificar de más obliga a uno a cargar con lo del otro.
• Enseña el recuento junto al botón de descargar. Si los dos salen del mismo sitio, quien descargue puede comprobarlo solo.
• Ofrece pocos filtros. Menos superficie donde divergir, y además la gente encuentra el que necesita.