Windows Me: cuando la fecha se convierte en requisito

Hoy, 14 de septiembre, cumple años Windows Millennium Edition. Salió el 14 de septiembre de 2000 y suele aparecer en las listas de peores versiones de Windows, cuando no de peores sistemas operativos.

Lo interesante no es que fuera malo. Es por qué existió, porque ese motivo se repite en muchos proyectos que no tienen nada que ver con sistemas operativos.

El escritorio de Windows Me. Captura de Windows Me (Microsoft, 2000), reproducida con fines informativos. Derechos de sus titulares.

Un producto puente

A finales de los noventa, Microsoft mantenía dos líneas en paralelo: la rama 9x, orientada a consumo y construida todavía sobre MS-DOS, y la rama NT, orientada a empresa y con una arquitectura moderna que ya no dependía de MS-DOS.

El plan era unificarlas: llevar la rama NT al mercado doméstico y jubilar la de consumo.

El plan se retrasó: Neptune —el Windows doméstico sobre NT— y Odyssey —el de empresa— acabaron cancelados y refundidos en Whistler, que salió como Windows XP.

Y ahí aparece la pregunta que decide esta historia: si la versión buena no llega a tiempo, ¿sacamos algo o no sacamos nada?

Sacaron algo. Windows Me fue un desarrollo corto sobre la rama vieja, con un puñado de funcionalidades nuevas encima, que acabó cubriendo el hueco hasta que llegó la plataforma doméstica basada en NT. Poco más de un año después llegó Windows XP y dejó a Me convertido, retrospectivamente, en lo que había sido: una transición.

Que fuera un producto de transición está claro. Que existiera solo para llenar una campaña de Navidad es lectura mía, no una motivación que Microsoft haya reconocido nunca. Lo que sí se puede afirmar es que salió con el reloj encima.

Cinco años antes, Windows 95 había partido del extremo contrario: un producto con una idea detrás y una migración que no obligaba a tirar nada. La distancia entre los dos casos es de cinco años y de un plan.

Lo que traía, que no era todo malo

Conviene ser justo, porque el chiste fácil tapa la parte útil:

• Restaurar sistema. La capacidad de volver el equipo a un estado anterior sin reinstalar. Una idea excelente, que en aquella primera versión funcionaba de forma irregular y que además podía devolverte también aquello de lo que querías escapar. Sigue en Windows veintiséis años después.
• Actualizaciones automáticas con una integración mucho mayor que antes.
• Movie Maker y un paquete multimedia razonable para la época.
• Un arranque más rápido.

Ese arranque más rápido se consiguió, en parte, quitando el acceso al MS-DOS en modo real.

Quitar la salida de emergencia

Aquella decisión tenía una lógica técnica defendible: el modo real era un lastre y su ausencia aceleraba el inicio. Y sin embargo es la que mejor explica el rechazo que se llevó el producto.

Porque el acceso a DOS no lo usaba la mayoría. Lo usaba precisamente una minoría especialmente importante para la plataforma: quien instalaba juegos antiguos, quien arrancaba desde disquete para reparar el equipo de un familiar, quien tenía un programa a medida de 1994 del que dependía una empresa entera.

Esa minoría es la que recomienda, la que instala, la que da soporte gratis a su entorno. Cuando le rompes su vía de escape sin darle otra, no pierdes su uso: pierdes su recomendación.

Es un patrón muy reconocible:

• La API antigua que se retira porque «ya casi nadie la usa». Ese casi nadie son tres integraciones que sostienen a tus clientes más grandes.
• La opción avanzada que se elimina para simplificar la interfaz. La usaban veinte personas, y esas veinte eran las que formaban al resto.
• La exportación a CSV que se sustituye por un panel bonito. El panel es mejor. El CSV alimentaba la macro de la que dependía el cierre mensual.

No es un argumento para no retirar nunca nada —quitar cosas es justo lo que casi nadie hace—, sino un argumento para retirar con ruta de salida: aviso con antelación real, alternativa documentada y un período en el que conviven las dos cosas. La deprecación sin sustituto no es simplificar, es delegar el problema en el usuario.

La fecha como requisito

Windows Me se parece mucho a un producto diseñado hacia atrás desde una fecha: cuando el calendario es el requisito duro, el alcance se convierte en la variable y acabas construyendo con lo que puede llegar a tiempo.

No sé si esa fue literalmente la conversación dentro de Microsoft. Tampoco hace falta saberlo para reconocer el patrón.

Ese producto tiene síntomas reconocibles a distancia:

• Nadie es capaz de explicar en una frase para quién es.
• Su lista de novedades es un inventario, no una idea.
• Se justifica en presente por lo que traerá la versión siguiente.
• La conversación interna gira alrededor de la fecha, no del problema del usuario.

Y hay una opción que casi nunca se pone sobre la mesa: no sacar una versión porque toca. Mantener lo que funciona, seguir corrigiéndolo, comunicar que la versión grande llega más tarde y no gastar la credibilidad en una entrega tibia.

Cuesta defenderlo porque parece pasividad, y porque en la mayoría de las organizaciones no publicar no se cuenta como decisión. Pero el coste de un lanzamiento tibio no es cero: es la reputación con la que después tienes que vender el bueno. Restaurar sistema arrastró durante años la desconfianza que se ganó en su primera versión, siendo una función que merecía mejor suerte.

Lo que sí hizo bien, aunque tarde

Por cerrar en justicia: la corrección llegó rápido. La unificación de las dos ramas se completó en 2001, y el resultado fue Windows XP, que acabaría sobreviviendo muchísimo más de lo previsto. El caso contrario, por cierto: un producto que duró demasiado.

Si una versión acaba siendo un parche, sustituirla pronto es, dentro de lo malo, la mejor salida posible.

Feliz aniversario

Tres preguntas para hoy:

1. ¿Cuál de tus entregas de este año existe por el calendario y no por el usuario? Solo hay que mirar cómo empezó la conversación: si empezó por una fecha antes que por un problema, hay una pista.
2. ¿Qué has retirado sin ofrecer alternativa? Búscalo en las notas de versión de los últimos doce meses. Suele estar redactado como una mejora.
3. ¿Quién es tu minoría que sostiene la plataforma? Los que dan soporte a los demás, los que hacen las integraciones raras. Si no sabes quiénes son, no sabes a quién estás rompiendo cuando simplificas.

(Y si alguien propone sacar una versión intermedia mientras llega la que de verdad resuelve el problema, hay un precedente de veintiséis años que merece al menos sacar a la conversación.)