Cómo fallar en el desarrollo – distinguiendo lo importante de lo accesorio

Martin Fowler escribió un interesante artículo llamado TransMediaApplication en el cual explica un problema común que se presenta a la hora de desarrollar aplicaciones para distintos dispositivo. Creo que esta frase resume todo el artículo: A common mistake is to think of different apps for different delivery devices.

En mi experiencia este escenario no se presenta solo cuando se trata de aplicaciones que corren en distintos dispositivos sino que se presenta con mucha mayor frecuencia de lo que se cree. El caso es que lo que Martin Fowler describe es un caso muy particular de un problema mayor: no comprender de que se trata en parte la arquitectura.

Lo voy a explicar con un ejemplo. Imaginemos que una empresa de transporte de carga nos pide desarrollar un sistema de seguimiento de sus vehículos. Estos vehículos tienen rutas específicas por las que deben transitar y tienen además una velocidad máxima autorizada. Nuestro cliente quiere conocer la ubicación de cada uno de sus camiones y sus velocidades (entre otras miles de cosas) prácticamente en tiempo real o con una demora no mayor a 1 minuto.

Para esto, cada vehículo tiene incorporado algún tipo de dispositivo móvil con GPS (o alguna variante). Nuestro cliente quiere visualizar la posición de sus vehículos en un mapa (en principio, mapas de google) y quiere poder hacerlo desde su dispositivo móvil.

Ahora bien, si quien lee esto fuese el responsable del desarrollo de este sistema… ¿por donde comenzaría?. Muchas personas comienzan por interiorizarse sobre los distintos modelos de dispositivos móviles incorporados a los vehículos, comienzan a interiorizarse por los diferentes sistemas de coordenadas que manejan, por los distintos mecanismos de despacho de esas coordenadas, esto es, si tienen conexión a internet continua, si soportan mensajes SMS, si http, tcp o udp, por los servicios que soportan en cada uno de sus puertos, etc. Luego, continúan por estudiar las apis de google maps, los lenguajes en los que esas apis están disponibles y demás consideraciones sobre cómo trabajar con esos mapas. Por último posiblemente, querrán conocer desde que tipo de dispositivo móvil es que el cliente quiere poder consultar la información.

Todo lo anterior está mal! No quiero decir que no deba hacerse ya que tarde o temprano conocer estas cosas será muy necesario, pero está mal porque denota una falta de análisis reflexivo sobre qué es lo que se debe desarrollar y sobre qué es lo que el cliente (negocio) necesita. Veamos, en la descripción del problema existen varios elementos que debemos notar y sobre los que tenemos que reflexionar, estos son: seguimiento, rutas, posición, velocidad, vehículo, dispositivo móvil, GPS y mapa. Existen otros elementos mencionados directa o indirectamente, pero quiero focalizarme solo estos.

A estos elementos debemos agruparlos en dos categorías: esenciales y accidentales. Así, posición, ruta, velocidad y seguimiento son esenciales mientras que dispositivo móvil, GPS y mapa son accidentales. Vehículo, por su parte, es un sinsentido. Si bien por alguna razón, las descripciones de los problemas que nos proveen los clientes suelen abundar en elementos accidentales, es nuestra responsabilidad el identificarlos y catalogarlos como tales en primera instancia.

El sistema a desarrollar debe, en principio, ser totalmente independiente de consideraciones superfluas como el protocolo de comunicación por medio del cual recibirá la posición de los vehículos. Si lo hace mediante TCP, UDP, por mensajes SMS o por correo twitter no es relevante en principio. Tampoco lo es la manera en que la información será presentada, ni si los clientes corren en dispositivos móviles o en PCs de escritorio, sobre un web browser o una aplicación nativa. Todas estas cosas deberán abordarse en su momento pero es importante comprender que se debe esperar a que llegue ese momento.

¿Y mientras tanto qué? Bueno, mientras no llegue el momento de encarar los detalles debemos centrarnos en resolver el problema esencial: desarrollar el sistema de seguimiento. Esto es lo primero!

En el software como en la vida, no distinguir lo importante de lo accesorio es el camino seguro al fracaso.

Sin categoría

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *