El presupuesto de una aplicación

Un presupuesto razonable

Los números no son leyes: dependen de qué haga tu aplicación. Lo que no depende es la obligación de tener algún número escrito para cada fila.

De dónde salen los umbrales de percepción

Y merece saberlo porque explica por qué esos y no otros:

• Por debajo de unos 100 ms, una respuesta se percibe como consecuencia directa de la acción: el usuario no siente que espera.
• Hasta un segundo, se percibe como rápido pero se nota; el flujo de pensamiento se mantiene.
• Más de un segundo, la atención empieza a irse, y hace falta mostrar algo para que el usuario sepa que la aplicación está viva.
• Más de diez segundos, la persona se va a hacer otra cosa, y entonces conviene una notificación al terminar. Nivel 50.2.

Esos cuatro umbrales llevan décadas siendo los mismos porque no dependen de la tecnología sino de la percepción, y son los que ordenan qué necesita indicador de progreso y qué no.

Defender el presupuesto

Lo difícil, porque una aplicación crece y los números empeoran solos:

El paso 4 es el que evita que el presupuesto se vuelva una ficción: un objetivo que nadie cumple deja de ser un objetivo. Ajustarlo con una razón escrita mantiene su utilidad.

Cuándo un número deja de ser razonable

Y hay casos legítimos:

• Si empaquetas un acompañante grande, el tamaño se dispara y no hay nada que hacer. El número pasa a ser «el instalador menos el acompañante».
• Si tu aplicación carga un modelo o un conjunto de datos grande, la memoria en reposo cambia de escala.
• Y si el arranque incluye una migración larga, el número de «hasta poder trabajar» no aplica esa vez — pero sí el de «hasta ventana visible», que debe seguir cumpliéndose mostrando el progreso. Nivel 43.3.

La distinción que se mantiene siempre: da igual lo que tarde el trabajo, la ventana tiene que aparecer rápido. Eso no se negocia con ningún presupuesto.