Regla N°4 de la Ingeniería de Software: Todo sistema tiene un propósito.

Olvidar el propósito de un sistema, es condenarlo al fracaso.

Hace bastantes años unos de mis primeros acercamientos al mundo de sus sistemas fue cuando estaba probando un sistema de PC que permitía dos personas compartir información (casi siempre texto), a través de un módem de 3200 baudios conectado a un puerto COM y a la línea telefónica convencional. No era a través de Internet (que no era ni barata ni común en aquel entonces), sino directamente con un módem llamando a otro módem, a través de un numero de teléfono convencional. Una vez, establecida la conexión, ambos usuarios se les permita intercambia frases y pequeños datos a través de esta con una velocidad extremadamente lenta. No era gran cosa, y sus posibilidades eran limitadas (tan limitadas que hubiera sido mejor una llamada telefónica normal), pero quede fascinado con el mecanismo que permitía a dos computadoras estaban unidas, a kilómetros de distancia, intercambiando bytes entre ellas. Cuando intente compartir con entusiasmo mi entusiasmo sobre la posibilidad en la que dos ordenadores podían intercambiar datos entre ellos, una persona me señalo que lo realmente impresionante, es que dos personas podían intercambiar datos entre ellas. Jamás se me ocurrió verlo así, para mí solo era un intercambio de bytes, cuando realmente representaba una comunicación e intercambio de información entre personas, objetivo real del software.

Esa fue una de las primeras lecciones de ingeniera de software que recibí. No podemos tener una visión puramente técnica de los sistemas y olvidar las necesidades operativas o de negocio para los cuales son realmente creados.

Es común que olvidemos que lo que estamos creando no es un conjunto de variables, y líneas de código, sino que tiene que un significado y relevancia especial fuera del lenguaje de programación en el que los estamos creando. Por ejemplo, una trasferencia bancaria de un millón de dólares errónea no es una posición de memoria mal inicializada, sino que puede ser una pérdida real, o un sistema médico de monitores mal construido puede poner en juego vidas humanas. Hay que pensar en nuestros sistemas por lo que van a poner aportar en un negocio o los problemas que van a poder resolver y no como simples entes tecnológicos.

En metodologías clásicas, en las que esta separado el programador del cliente, y se llega a construir el software por una serie de fases encadenadas claramente diferenciadas, en normal que el programador se centre en los aspectos tecnológicos de la solución olvidando el motivo de la solución misma. Esto crea sistemas técnicamente correctos, pero que sirven de poco, al no satisfacer las necesidades del cliente. En la nuevas metodologías agiles, se intenta que el cliente sea parte del equipo, con lo que es mas fácil comprender su punto de vista y aprovechar su conocimiento para crear un sistema funcional.

Es importante recordar que nuestro sistema es un ente que después va a ser usado por alguien, si nuestra sistema no se pueda usar más que en un ambiento de desarrollo y por nosotros mismos, no resuelve nada. Igualmente Hay que poner el propósito (la necesidad, el por qué se hacen las cosas) en primer lugar y usarlo como nuestro camino y nuestra guía para encontrar la solución.