El Nokia 3310 duraba una semana, y no era solo por la batería

Hoy, 1 de septiembre, cumple años el teléfono que todo el mundo recuerda haber tenido, aunque las cuentas no salgan. Nokia anunció el 3310 el 1 de septiembre de 2000 y acabó vendiendo unos 126 millones de unidades.

Para dar la escala: el primer iPhone, el de 2007, vendió unos 6,1 millones en toda su vida comercial. La comparación no es homogénea —ni en precio, ni en mercados, ni en tiempo a la venta—, pero sirve para hacerse una idea del tamaño.

El Nokia 3310, presentado en el año 2000. Foto: Multicherry, CC BY-SA 4.0; imagen recortada y disponible bajo la misma licencia.

Mi primero fue el anterior

Yo soy uno de esos que no cuadran: nunca tuve un 3310. Mi primer móvil fue el Nokia 3210, el modelo al que el 3310 vino a sustituir. Nokia lo presentó en el CeBIT el 18 de marzo de 1999 y acabó vendiendo unos 160 millones de unidades: su antecesor vendió incluso más que él. Yo lo recordaba de 1998, y las fechas dicen que no: hasta la primavera de 1999 no llegó a las tiendas.

Lo que impresionaba de aquel era que no tenía antena. Fue el primer teléfono de gran consumo con la antena metida dentro del aparato, y después de años de varillas asomando por arriba eso parecía venir del futuro. Traía Snake, el compositor de tonos y las carcasas de quita y pon; el 3310 heredó las tres cosas y añadió Snake II y los mensajes encadenados.

Y la línea era de Airtel, una marca que ya no existe. Fue la operadora que rompió el monopolio de Telefónica en la telefonía móvil: empezó a dar servicio el 3 de octubre de 1995 y en octubre de 2001, con unos siete millones de clientes, dejó de llamarse Airtel para llamarse Vodafone España. El aparato sigue en algún cajón y es probable que arranque; la marca bajo la que tenía cobertura lleva casi veinticinco años sin existir.

Lo que traía

Poca cosa, y esa es la tesis del artículo:

• Llamadas y SMS. Con una novedad discreta y muy usada: los mensajes encadenados, que permitían pasar de los 160 caracteres de golpe.
• Snake II, con paredes atravesables y niveles.
• Tonos componibles, que se intercambiaban escritos en un papel como si fueran partituras.
• Carcasas intercambiables, que se cambiaban en cualquier bazar por unas pocas pesetas.
• Una batería que aguantaba días.

No tenía cámara, ni navegador, ni tienda de aplicaciones, ni notificaciones, ni pantalla en color. Y su leyenda —que sobrevivía a cualquier caída— exagera una reputación de resistencia que sí tuvo.

La autonomía no dependía solo de la batería

Aquí está lo interesante, y es un argumento de ingeniería, no de nostalgia.

Con uso ligero aguantaba varios días, y cerca de una semana si apenas lo tocabas. Y eso no dependía solo de la batería, sino del conjunto: una pantalla monocroma, un aparato simple sin nada corriendo en segundo plano, sin radios adicionales encendidas todo el rato ni procesos despertando al sistema cada pocos segundos para preguntar si hay novedades, y un patrón de uso que hoy parece de otro planeta —unas llamadas, unos SMS y el resto del día parado en el bolsillo—. La cobertura también contaba: un teléfono buscando red se come la carga entonces igual que ahora.

Cada funcionalidad que le añades a un dispositivo tiene un coste que no aparece en la lista de características: consume energía, ocupa memoria, añade estado que puede corromperse y, sobre todo, añade una cosa más que puede fallar mientras haces otra cosa.

Esto no es una queja contra los teléfonos actuales, que son mejores en casi todo. Es una observación sobre un tipo de coste que casi nunca se contabiliza cuando se decide añadir algo.

El presupuesto de complejidad

Cuando alguien propone una funcionalidad nueva, la discusión suele ser sobre el coste de construirla. Y ese es el coste barato: se paga una vez.

El caro es el otro:

• Hay que mantenerla mientras exista. Cada dependencia que actualices, cada migración de base de datos, cada cambio de diseño tendrá que pasar por ahí.
• Hay que probarla. Y no sola: en combinación con lo demás. La superficie de pruebas no crece con el número de funcionalidades, crece con sus combinaciones.
• Hay que explicarla. En la documentación, en el soporte, en la formación de cada persona nueva.
• Hay que decidir qué hacer con ella cada vez que algo cambie alrededor. Durante años.

Un equipo tiene un presupuesto de complejidad, igual que el 3310 tenía un presupuesto de energía. La diferencia es que el del teléfono se veía en la barra de la batería y el del equipo solo se ve cuando ya está gastado: en la velocidad a la que se entrega, en el miedo a tocar según qué módulo, en los tres días que cuesta ahora un cambio que antes costaba dos horas.

Preguntas que ayudan antes de decir que sí:

1. ¿Qué quitamos a cambio? Si la respuesta siempre es «nada», el presupuesto no existe.
2. ¿Quién lo mantiene dentro de dos años? Con nombre, no con «el equipo».
3. ¿Qué resultado justificaría mantenerlo? Definido antes de construirlo y comprobado después, no estimado. Y no solo en número de usuarios: también en el valor que aporta y en quién depende de ello.

Esa tercera es la que casi nunca se cumple. Añadir es una decisión que se celebra; quitar es una decisión que hay que defender. Y por eso, si nadie introduce la decisión contraria, los productos tienden a crecer.

Lo que la nostalgia no cuenta

Por honestidad: escribir un SMS en un teclado numérico era lento y torpe. Los tonos se agotaban rápido. Casi nada de lo que hoy das por sentado existía. Yo no quiero volver.

Lo que me interesa de esa nostalgia no es el teléfono, sino la previsibilidad. Sabías exactamente lo que hacía, sabías que estaría cargado y sabías que no iba a cambiar solo por la noche.

Eso sí se puede recuperar en lo que construyes hoy. No renunciando a funcionalidades, sino haciendo que las que hay se comporten siempre igual. Una herramienta previsible se usa a ciegas; una herramienta sorprendente exige atención cada vez.

El museo del cacharro

Estrenamos con esto una sección de aniversarios de hardware. No por coleccionismo, sino porque los cacharros con restricciones severas son los que mejor enseñan a diseñar: cuando no te sobra nada, cada decisión se ve.

Es la misma idea que aparece en los videojuegos de la época, que llevan cuarenta años enseñándonos cosas que copiamos mal, y en el diseño de interfaces de aquel Windows que había que aprender con las manos.

Feliz aniversario

Tres cosas para hoy:

1. Haz la lista de funcionalidades de tu producto que usa menos del 5 % de la gente. Si no puedes hacerla porque no lo mides, ese es el trabajo de esta semana.
2. Elige una y averigua por qué sigue ahí. El porcentaje no decide: señala dónde preguntar. Mide su valor, quién depende de ella y qué pasaría si desapareciera. Si no encuentras una razón suficiente, propón retirarla. Y observa la resistencia que aparece: también es información sobre cómo se decide en tu equipo.
3. Mira qué está corriendo en segundo plano en tu aplicación. Procesos, tareas programadas, sondeos cada pocos segundos. Alguno lleva años preguntando algo que ya no interesa a nadie.

(Y si encuentras uno en un cajón, ponle una carcasa nueva y enciéndelo. Es muy probable que arranque.)