El pasado mes de agosto, durante mis merecidas vacaciones, estaba viajando en un autobús por Manhattan y me llamó la atención algo que a priori parecía insignificante: un cordón de color amarillo que recorría el lateral del vehículo, junto a las ventanillas.
Era el mecanismo para solicitar parada.
Tiras de él. Se activa el aviso. El conductor sabe que alguien quiere bajar en la próxima parada. Y ya está.
En una época en la que un autobús puede incorporar GPS, cámaras y pantallas de información al pasajero, decir «quiero bajarme en la próxima parada» sigue pudiendo resolverse tirando de un cordón.
Lo interesante es que su regreso tuvo una razón práctica. La agencia New York City Transit había ido abandonando el cordón y, décadas después, decidió recuperarlo en los vehículos nuevos. Para quienes trabajamos con software y sistemas, la pregunta es inevitable: ¿por qué nos sorprende que algo sencillo siga siendo una buena solución?
Una historia que no avanza en línea recta
Según la crónica de A. G. Sulzberger publicada en The New York Times el 12 de mayo de 2009, los bell cords (cables amarillos) ya se utilizaban en tranvías a finales del siglo XIX y se incorporaron después a los autobuses de motor.
En la flota de New York City Transit, los cordones empezaron a ceder terreno a partir de 1980 ante las bandas amarillas que se presionaban para solicitar parada. Según la crónica, en 1992 se retiró el último autobús con cordón de aquella generación.
Pero en 2008, al adquirir una nueva serie de autobuses híbridos Orion VII, la agencia decidió recuperar el cordón. Cuando el Times contó la historia en mayo de 2009, ya había 270 buses nuevos equipados con él.
Los nuevos autobuses combinaban la moderna tecnología híbrida para ahorrar combustible y reducir emisiones con una solución de toda la vida: un cordón para pedir parada. Modernizar el vehículo no exigía reinventar cada una de sus piezas.
El regreso tenía una explicación muy poco romántica
La razón era práctica: el cordón era más barato de instalar y reparar. Según el portavoz de New York City Transit citado por el Times en 2009, los costes por autobús eran:
Sistema de bandas sensibles a la presión: 1.056 dólares por autobús.
Sistema de cordón: 293 dólares por autobús.
El sistema de cordón costaba aproximadamente un 70 % menos que el de bandas. Su regreso respondía al ahorro y a la reparación, más que a simple nostalgia.
KISS: la complejidad necesaria
KISS significa Keep It Simple, Stupid, cuya idea central es «mantenlo sencillo». El principio, asociado habitualmente al ingeniero aeronáutico Kelly Johnson, propone hacer de la simplicidad un objetivo del diseño y evitar complejidad que no aporte valor.
El regreso del cordón ilustra esa idea: una solución conocida puede seguir cumpliendo su cometido y resultar más económica de mantener. Las bandas no eran necesariamente un mal diseño, pero la diferencia de precio plantea una pregunta: ¿qué aporta el coste adicional cuando ambas opciones resuelven la misma necesidad?
En software, aplicar KISS no significa escribir el programa más corto ni utilizar siempre la herramienta más antigua. Significa buscar una solución que el equipo de desarrollo pueda entender, utilizar, comprobar y modificar sin grandes dificultades.
El cable amarillo lo ilustra bien: para pedir parada basta con transmitir un mensaje al conductor, «quiero bajar en la próxima». Aunque el autobús incorpore tecnología avanzada, ese gesto puede seguir siendo sencillo. En software conviene hacerse la misma pregunta: ¿qué necesita resolver realmente el usuario y qué estamos añadiendo nosotros? No todos los problemas necesitan convertirse en plataformas.
Nuestro cable amarillo puede ser una tarea programada
Imaginemos que una tienda recibe cada noche un archivo de su proveedor con los precios actualizados. Necesita comprobarlo y trasladar esos precios a su catálogo. Si el archivo es pequeño y basta con actualizar una vez al día, puede ser suficiente un programa que haga ese trabajo automáticamente a una hora fijada y avise si algo sale mal. Eso es una tarea programada.
También podríamos construir una plataforma con varios programas conectados, un panel de control y actualizaciones en tiempo real. Pero, si la tienda solo necesita tener los precios listos al abrir, ¿qué ganamos con todo eso?
Una solución más compleja puede tener sentido si llegan archivos de muchos proveedores o los precios deben cambiar al instante. La cuestión es elegirla porque hace falta, no simplemente porque podemos construirla.
Lo sencillo también debe estar bien hecho: comprobar que los precios sean válidos, proteger el acceso al catálogo y permitir repetir el trabajo sin crear errores. Nuestro cable amarillo sería esa pequeña automatización: hace lo necesario y podemos entender cómo funciona.
Con IA, más motivos para aplicar KISS
Con la inteligencia artificial como ayuda para desarrollar software, creo que KISS es más importante que nunca. Si añadir una función parece tan fácil como pedirla, es tentador aceptar un «ya que estamos» detrás de otro. Así podemos caer en la sobreingeniería: construir algo más complicado de lo que el problema necesita.
En nuestra tienda, podríamos pedirle a la IA que añadiera informes, gráficos y opciones para proveedores que todavía no tenemos. Que pueda ayudarnos a crearlos no significa que hagan falta. Cada añadido seguirá necesitando revisión, pruebas y mantenimiento.
También podemos usar la IA para simplificar: pedirle que proponga la solución mínima que cumple lo necesario y que explique qué aporta cada pieza. Cuanto más fácil resulta añadir, más importante es saber cuándo parar.
La mantenibilidad también es una funcionalidad
Cada componente que introducimos genera trabajo futuro: actualizarlo, vigilar su funcionamiento, documentarlo y resolver los fallos que pueda ocasionar. A veces ese coste compensa ampliamente; otras, solo desplazamos el trabajo hacia un lugar menos visible.
La complejidad es un presupuesto limitado. Conviene gastarlo donde aporte valor.
No basta con que algo funcione el día de la demostración: alguien tendrá que mantenerlo durante años. Además de preguntar si un programa es rápido y funciona cuando lo necesitamos, deberíamos pensar cuánto tardará otra persona en entenderlo cuando falle.
A las tres de la madrugada, cuando un servicio deja de funcionar, importan tres preguntas: ¿dónde falla?, ¿por qué?, ¿cómo lo arreglo? Un diseño comprensible, mensajes de error útiles e instrucciones de recuperación probadas también forman parte de una buena solución.
El peligro suele empezar con un «por si acaso»: por si mañana tenemos diez proveedores, abrimos más tiendas o necesitamos actualizar los precios cada minuto. Anticipar riesgos es parte del trabajo; convertir cualquier posibilidad en una obligación inmediata puede alejarnos del problema real.
Aquí KISS se encuentra con otra idea: no construir hoy lo que solo suponemos que necesitaremos mañana. Se conoce como YAGNI, You Aren’t Gonna Need It. Martin Fowler explica que anticipar esas funciones puede retrasar el trabajo útil y añadir complejidad. Aplazarlas exige cuidar el programa y comprobar que sigue funcionando al modificarlo. En nuestra tienda, podemos dejar escrito qué cambio justificaría ampliar la solución, en lugar de prepararla desde el principio para todos los futuros imaginables.
Sencillo no significa incompleto
La sencillez también debe facilitar la tarea a quien usa la solución. En el autobús, no basta con instalar un cordón: el pasajero tiene que poder alcanzarlo y saber que su petición de parada ha quedado registrada. Un botón al alcance o una luz de confirmación pueden ser tan necesarios como el propio cable.
Con la tienda ocurre lo mismo: automatizar la actualización de precios sirve de poco si nadie sabe que ha fallado y el catálogo sigue mostrando los del día anterior. Simplificar es quitar lo que sobra, conservando lo que hace que la solución sea útil y fiable.
El test del cable amarillo
Antes de añadir otra herramienta o complicar un sistema, conviene responder a estas preguntas:
¿Qué problema concreto resuelve?
¿Cuál es la solución más sencilla que cumple los requisitos reales?
¿Qué nuevos fallos puede provocar?
¿Quién podrá mantenerla dentro de tres años?
¿Qué evidencia justificaría una solución más compleja?
¿Qué ocurre si no añadimos esta tecnología?
Si las respuestas justifican un sistema más complejo, adelante. Si basta con una tarea programada o una herramienta conocida, también. El objetivo es poder explicar por qué cada pieza está ahí.
La mejor arquitectura es la que resuelve correctamente el problema con la complejidad necesaria. Ni más. Ni menos.
La próxima vez que esté a punto de añadir otra herramienta o una función más, recordaré aquel autobús de Manhattan y me preguntaré: ¿realmente necesito todo esto o bastaría con mi equivalente al cable amarillo?
Créditos fotográficos
Interior del autobús: GK tramrunner RU. Banda amarilla e indicador de parada: Tdorante10. Wikimedia Commons · CC BY-SA 4.0. Sin modificaciones.
_08.jpg){kind=link}
