Una de las lecciones que más cuesta aprender para un buen programador es la siguiente: programar NO es lo más importante en el software. Un poco irónico, pero cierto. Para ser más específicos, hacer del software un negocio NO se hace programando. Claro, nos toca el orgullo, el karma, el ego. Nos gusta sentirnos esenciales en el proceso. Pero no, al final somos los peones de todo el camino. No nos estoy desprestigiando, somos peones de alto nivel, difíciles de conseguir, que podemos ser caros y lo demás…pero somos altamente reemplazables, y en rol de negocio NO jugamos un papel importante. Así como los cortadores de café no son claves en el negocio del café, o los cocineros en un restaurante de comida rápida poco tienen que decir ese negocio, o como los ingenieros químicos de comidas empacadas tienen poco que decir en su negocio. De nuevo son puestos CLAVES siempre y cuando EXISTA y FUNCIONE el negocio. Pero ellos, al igual que nosotros, no suelen influir desde el punto de vista de negocios.

Aquellos a quienes nos gusta desarrollar software, sabemos que podemos hacer muchas cosas, y creemos que podemos hacer cualquier cosa. Iniciar un proyecto es barato y sencillo, y por lo general, nos gusta involucrarnos mucho en nuestras nuevas y brillantes ideas. Y caemos en la tentación de pensar que si desarrollamos un sistema que hace tal o cual maravilla, la gente ira corriendo a nuestras oficinas a solicitarnos instalaciones. Pero el mundo no funciona así.

Intentando unificar la industria del software con otras industrias me pongo a pensar. ¿Qué hace que una fábrica de vehículos sea eficiente? ¿Son acaso los que manufacturan las diversas partes del vehículo? ¿O son los que aplican la pintura? ¿A lo mejor los que hacen los diseños nuevos? Mmmm, seguramente son los que  perfeccionan los diseños de motores….NO!!!! Si bien las personas que realizan estas tareas son VITALES para el funcionamiento de la fábrica de carros, no son los que hacen que la fábrica de carros sea exitosa. Son los puestos ejecutivos los claves (me cuesta decir esto, aunque resulte obvio).

Pero a nosotros nos cuesta, y nos cuesta mucho darnos cuenta de esto. Desarrollar software es un proceso complejo y que consume muchos recursos mentales, y sobre todo mucho tiempo. Mientras desarrollamos nos enfocamos en sólo eso, en desarrollar, en programar, y eso nos deja poco tiempo para el proceso creativo fuera del software.

Aprendimos una vez que un producto de software es más que el código compilado: que la documentación es importante, que el soporte es importante, que la atención al usuario es importante, que las ventas son importantes, que lo visual es importante, que el mercadeo es importante, y ¿adivinen qué? se nos olvida eso!

Usemos el siguiente ejemplo:  dos personas que conciben una misma idea para un software. Para no hacer nada complicado, pensemos que la idea es vender en línea tickets de cine con combos de comida incluídos. La primera persona que lo piensa es un “hombre de negocios¨, y la otra es un programador que es un gurú en la materia. ¿Qué camino tomará cada uno? El hombre de negocios buscará quien le asesore para “comprar” o “hacer” el software que quiere; buscará también quien le haga el mercadeo, buscará socios capitalistas para financiar el proyecto, buscará las mejores estrategias para vender la idea, pondrá especial interés en el retorno de la inversión en el tiempo.

Por otro lado, uno de nosotros tomará un camino distinto. Pensaremos en qué plataforma VAMOS a desarrollar el producto, que features bonitos le podemos poner. Haremos una medio medición de cuanto nos tomará el desarrollo. El costo ni nos preocupa porque al fin, lo vamos a hacer NOSOTROS. Si algún día llegamos a terminar el desarrollo, tal vez comenzaremos a buscar una manera de hacer una campaña en línea y ver la manera de que algunas personas puedan encontrarnos por google y por facebook. En cuanto a retorno de la inversión, pensamos que lo peor que haya pasado es que hayamos perdido NUESTRO tiempo. Y bueno, con las ventas….pues las ventas de un producto bueno solitas se darán.

¿A quién le irá mejor?

No related posts.

El correo electrónico, email, es una de las herramientas más utilizadas como medio de comunicación en un proyecto de software. A través del email se establece comunicación con los clientes y entre los miembros del equipo de desarrollo. Usualmente el uso del email se extiende a todos los ámbitos del proyecto: factibilidad, levantado de requerimientos, desarrollo, mantenimiento, resolución de dudas, propuestas de ideas, y un gran etcétera.

Aunque el email es una gran herramienta, en la actualidad hay un “sobre uso” del correo. Para absolutamente todo se hace un nuevo mail. Y en muchas ocasiones, el email no es la mejor herramienta para solucionar los problemas. Quiero aclarar que estoy hablando de proyectos de chicos a medios, proyectos en los que una empresa naciente se involucra. Para proyectos más grandes hay otras herramientas que generalmente se utilizan, que de no utilizarse no sería posible el desarrollo en gran escala.

Este es un tema de manejo de proyectos, asunto sobre el cual quiero dedicarle algunos posts. El manejo de proyectos es uno de los grandes puntos grises del desarrollo de software, y un área que poco interés se suele poner en las empresas. Cada vez más me convenzo de que un buen software está íntimamente ligado a un buen manejo de proyecto.

Pero volviendo al tema, NO ES SENSATO utilizar el mail para todo. Seguro les ha tocado más de una ocasión buscar un documento que enviado por un cliente, que sabe Dios dónde se encuentra en su inbox (o su respectiva carpeta o tag). Y luego de 20 minutos de búsqueda el archivo buscado estaba en un mail con “No Subject” que su cliente envío hace un par de meses. O quieren ver la versión de la especificación en la que se contemplaba x o y característica del producto que ahora ya no está contemplada, o la fecha de entrega, etc.

Y dependiendo del rol que cumplan en el proyecto, la avalancha de mails puede parecerles SPAM. Si ustedes son parte del equipo de ventas, pero están incluídos en el CC (y son uno de los 25 destinatarios de CADA mail del proyecto) le perderán la pista a las cosas importantes. Además cada quien tiene una configuración distinta para responder, y de pronto la “conversación” se vuelve un hilo de mails que pocos entienden.

El email funciona muy bien para muchas cosas, pero cada vez veo más claro que como método de almacenamiento de conocimiento no es una buena herramienta. Como menciono hay herramientas alternativas, software para manejar proyectos, para almacenar documentos, etc. Pronto haré una lista de software disponible para esto. Hay herramientas que almacenan mejor el conocimiento, que lo pueden indexar de distintas maneras, que pueden buscar relaciones, que pueden intentar estructurar el conocimiento, y que no excluyen el email. Hay algunas herramientas que consideran los replys de los mails…y es una gran cosa.

Una lista de razones por las que considero que hay que buscar alternativas al mail para manejar el flujo de información en un proyecto:

• El conocimiento se vuelve, hasta cierto punto restringido. Sólo los destinatarios poseen el conocimiento sobre el proyecto, lo que de principio le reduce la vida. Claro, hay cosas confidenciales, pero hay muchas otras que son del interés común tanto de la empresa proveedora como el cliente.
• Es sumamente complicado de organizar. Aunque ahora existen maneras eficientes de manejar cada correo de entrada, los correos en los que se tratan distintos temas, se vuelven un desafío.
• Mucha información puede volverse ruido. Si todas las mail de un proyecto se van a la carpeta “Proyecto X” de nuestro manejador de correo, de pronto tendremos una carpeta con miles de correos que no nos sirven, a lo más para hacer búsquedas.
• No se escriben buenos mails. Abundan los mail con subjects malos, los mails de más, los mails mal escritos, los mails que no dicen nada, o que dicen algo en mucho, etc. Que es otro tema que algún día tocaremos, cómo y porque escribir buenos mails.

Pero hay un punto importante: mucha de la información sobre el proyecto sale del cliente, y el cliente USA EL EMAIL, y hacerlo utilizar otra herramienta, es prácticamente imposible. Así que la solución que se utilice DEBE usar el mail como interfase. Irónico pero cierto. Intentar que el cliente use “nuestra herramienta” es algo difícil de lograr, así que el mail debe ser utilizado, pero con un nuevo enfoque.

No related posts.

El patrón estructural que ahora vamos a analizar es muy eficaz así como sencillo. Se puede utilizar en muchos contextos y es de especialidad utilidad cuando se utilizan códigos o librerías ajenos al que estamos utilizando y sobre el que no tenemos control. Este patrón se le conoce como adaptador o adapter en inglés, aunque algunos lo llaman también wrapper, que viene siendo como envoltorio. Ambos nombres tienen bastante sentido y explican el por qué de este patrón.

Antes de comenzar con código o parecido, pensemos en este problema. En muchos países se utilizan las espigas redondas en los tomacorrientes, y en otros las espigas planitas. En ocasiones tenemos un dispositivo que tiene 3 espigas y el tomacorrientes 2. Sin embargo sabemos que el aparato que deseamos conectar “entiende” la corriente eléctrica, “la acepta”, aunque la interfaz para conectarse a ella sea una distinta a la que posee. ¿Qué hacemos en estos casos? Usamos un adaptador! O un convertidor, o un transformador, cómo le querramos llamar.  Pues lo mismo sucede con el software. Sucede a menudo que nos encontramos con librerías que pueden sernos de utilidad, pero que existe la necesidad de adaptarnos a ellas. En esos casos tenemos dos opciones: modificar todo nuestro código para que se adapte a la librería, o podemos crear un adaptadro que traduzca lo nuestro a lo de ellos y lo de ellos a lo nuestro. Un ejemplo sencillo en el mundo Java es el de los Enumeration y los Iterators. Ambos tienen un hasNext()  o  un hasMoreElements() que hacen lo mismo; al igual que un next() y un nextElement() que hacen lo mismo. Imaginemos todo lo queremos manejar con Iterators, podemos crear un adaptador que nos “convierta” entre Iterator y Enumeration.

Vamos con el usual ejemplo. Imaginemos tenemos un sistema que maneja coches, barcos, aviones y parecidos. Generalmente los motores que se usan son de gasolina, pero las nuevas tendencias han popularizado los motores eléctricos. Para simplificar mi caso y mostra bien el punto, tenemos que el proveedor de vehículos eléctricos nos provee sus librerías para el motor eléctrico que es prácticamente igual a nuestras implementaciones pero con otros nombres (prender en vez de encender, “mover más rápido” en vez de acelerar, etc.), y tiene una restricción extra: para poder acelerar o detener el motor, este tiene que estar conectado. Y surge el problema ¿cómo hacemos para nuestras librerías puedan hacer uso del motor eléctrico? Podríamos reescribirlas todas, pero el tiempo que eso nos tomaría sería mucho. Además sabemos que existirían problemas que nuestras librerías ya han solucionado.

Como nos gusta ser elegantes en nuestro uso de objetos, hace muchos años creamos una clase abstracta (pensamos también hacer una interfaz, pero la clase abstracta nos provee otros métodos útiles):

package com.guisho.software.patrones.adapter;
public abstract class Motor {
   abstract public void encender();
   abstract public void acelerar();
   abstract public void apagar();
   //...mas metodos que hacen muchas cosas
}

Y tenemos nuestras implementaciones de algunos motores, por ejemplo el motor económico:

package com.guisho.software.patrones.adapter;
 
public class MotorEconomico extends Motor {
 
    public MotorEconomico(){
        super();
        System.out.println("Craendo motor economico");
    }
 
    public void encender() {
        System.out.println("Encendiendo motor economico.");
    }
 
    public void acelerar() {
        System.out.println("Acelerando motor economico.");
    }
 
    public void apagar() {
        System.out.println("Apagando motor economico.");
    }
 
}

Y el motor gastón (que ya no se vende tanto!):

package com.guisho.software.patrones.adapter;
public class MotorGaston extends Motor {
    public MotorGaston(){
        super();
        System.out.println("Creando el motor gaston");
    }
 
    public void encender() {
        System.out.println("Bum, bum....encendiendo motor gaston");
    }
 
    public void acelerar() {
        System.out.println("Buuuuuuuuuuuum, acelerando y gastando muuuucha gas");
    }
 
    public void apagar() {
        System.out.println("Apagando motor gaston");
    }
 
}

Estas clases siempre nos han funcionado bien, y de hecho tienen muchas cosas como servicios, mantenimientos y otros, que usamos gracias a la interfaz motor. Por ejemplo es común que usemos cosas como estás:

        Motor motor = new MotorEconomico();
        motor.encender();
        motor.acelerar();
        motor.apagar();
       //hacer mas cosas....
        motor = new MotorGaston();
        motor.encender();
        motor.acelerar();
        motor.apagar();

Ahora la empresa que construye motores eléctricos nos manda su propia implementación que va así:

public class MotorElectrico {
 
    private boolean conectado = false;
 
    public MotorElectrico() {
        System.out.println("Creando motor electrico");
        this.conectado = false;
    }
 
    public void conectar() {
        System.out.println("Conectando motor eléctrico");
        this.conectado = true;
    }
 
    public void activar() {
        if (!this.conectado) {
            System.out.println("No se puede activar porque no esta conectado el motor electrico");
        } else {
            System.out.println("Esta conectado, activando motor electrico....");
        }
    }
 
    public void moverMasRapido() {
        if (!this.conectado) {
            System.out.println("No se puede mover rapido el motor electrico porque no esta conectado...");
        } else {
            System.out.println("Moviendo mas rapido...aumentando voltaje");
        }
    }
 
    public void detener() {
        if (!this.conectado) {
            System.out.println("No se puede detener motor electrico porque no esta conectado");
        } else {
            System.out.println("Deteniendo motor electrico");
        }
    }
 
    public void desconectar() {
        System.out.println("Desconectando motor electrico...");
        this.conectado = false;
    }
}

Como vemos, este motor hace lo mismo que el nuestro, pero de manera y con llamadas un poco diferentes. ¿Cómo hacemos para integrar este MotorEléctrico al resto de nuestro sistema? Así es, con un adaptador o adapter!
El adapter “envuelve” al objeto extraño (por eso le llaman wrapper también, ya que wrapper viene siendo envoltorio).

Nuestro adaptador se escribiría así:

package com.guisho.software.patrones.adapter;
 
public class MotorElectricoAdapter extends Motor{
    private MotorElectrico motorElectrico;
 
    public MotorElectricoAdapter(){
        super();
        this.motorElectrico = new MotorElectrico();
        System.out.println("Creando motor Electrico adapter");
    }
 
    public void encender() {
        System.out.println("Encendiendo motorElectricoAdapter");
        this.motorElectrico.conectar();
        this.motorElectrico.activar();
    }
 
    public void acelerar() {
        System.out.println("Acelerando motor electrico...");
        this.motorElectrico.moverMasRapido();
    }
 
    public void apagar() {
        System.out.println("Apagando motor electrico");
        this.motorElectrico.detener();
        this.motorElectrico.desconectar();
 
    }
 
}

Como ven el adapter se encarga no solo de corregir los nombres de los métodos, sino también cosas como conectar y desconectar el motor, cosas que a nuestra implementación no le importan. Pero lo más importante es que ahora podemos utilizar esta implemetnación de Motor en nuestro sistema utilizando la implementación de ellos. Por ejemplo podemos hacer cosas como esta:

        Motor motor = new MotorEconomico();
        motor.encender();
        motor.acelerar();
        motor.apagar();
 
        motor = new MotorGaston();
        motor.encender();
        motor.acelerar();
        motor.apagar();
 
        motor = new MotorElectricoAdapter() ;
        motor.encender();
        motor.acelerar();
        motor.apagar();

El patrón adapter aparece en todos lados, aunque muchas veces no se le llama adapter específicamente. Ahora que lo conocemos lo podemos usar en nuevos proyectos, o tal vez puede solucionarlos problemas que resolvimos a medias en algún software por ahí. Como siempre les dejo el código fuente.

Related posts:

1. Prototype Pattern – Patron Prototipo — Patrones de diseño
2. Builder Pattern, Interfaces Fluidas– Patrones de diseño
3. Abstract Factory Pattern – Patrones

Hace ya algunos años lei por primera vez este texto. Quisiera poner la referencia del autor, pero no encontré quien lo pudo haber escrito,  así que si alguien me dice a quién darle el crédito, con gusto se lo daremos Aparte de lo gracioso en sí mismo, ahora que lo leo años después, desafortunadamente es muy acertado. Digo desafortunadamente, porque tenemos que cambiar la manare de hacer proyectos de software. Urgentemente. Nuevas metodologías, nuevas herramientas, nuevos paradigmas. Actualmente el proceso de hacer software es más complicado de lo que, en mi humilde opinión, debería ser. ¿Qué piensan?

5 de enero
Hoy me han llevado al lugar de construcción por primera vez. La situación es perfecta: tiene parada de bus cercana y enfrente hay una cafetería con comida casera. El viejo edificio de apartamentos, al que va a sustituir nuestra nueva construcción, lleva un año al borde de la ruina. Mi propia empresa ha colocado varios puntales que, por el momento, han ido evitando que el caduco edificio reviente por sus múltiples grietas. La construcción de este megalito ladrillo comenzó hace cinco años, y aunque los pisos superiores nunca llegaron a recibir el agua, la electricidad y el enfoscado de las paredes, en diez meses los cimientos ya se habían desplazado peligrosamente y las vigas presentaban peligrosas fisuras. La cansada torre de viviendas ya ha cumplido su propósito y ahora nosotros la conduciremos a una muerte dulce… Por supuesto, el viejo edificio no será demolido hasta después de construir y probar el nuevo, lo que nos deja poco espacio de maniobra; pero no vamos a dejar a todas esas familias en la calle durante la construcción. De cualquier modo, los vecinos de la vieja y decadente estructura nos miran con recelo. Saben que el nuevo edificio tendrá viviendas cómodas, pero algunos de los residentes no podrán costearlas. Ni sé qué va a ser de la gente, ni es asunto mío. Llegan los primeros camiones de ladrillos.

6 de enero
Me han presentado a Matías, la persona a quien “voy a reportar”. No me han dicho si es el capataz, el jefe de obra, el aparejador, o el arquitecto; sólo me han dicho que todo lo que tenga que “reportar” se lo “reporte” a él. Así que, por donde él diga, yo zaca-zaca, como una locomotora. Esa es la definición que me han dado de nuestra metodología. He buscado “reportar” en el diccionario, y no aparece.

10 de febrero
En algo más de un mes, hemos cavado medio metro de cimientos. Ayer Matías nos dijo que empezáramos a poner ladrillos, porque el tiempo designado para la cimentación se había agotado hace dos semanas. No aceptó nuestras excusas de que las prometidas excavadoras aún no habían llegado y que nos habíamos visto obligados a cavar con las paletas de enyesar. Un compañero se trajo un pala de cavar que guardaba de una obra anterior y casi le echan por razones deontológicas. Según Matías, lo que pasa es que frecuentamos demasiado la cafetería. El asunto se ha zanjado con un “hale”, a levantar paredes y luego que cada palo aguante su “vela”. El trabajo sin planos es dificultoso. Los cimientos tienen una forma algo pintoresca. He pedido una plomada para que las paredes queden verticales y he recibido improperios poniendo en duda mi masculinidad. Ya sé que Matías no es el arquitecto, porque el arquitecto es un tal Ignacio. Pasó a supervisar la obra el otro día. Aunque aún no había nada que ver. Me han llegado rumores, aunque no son muy dignos de crédito, de que existen fotocopias de planos.

1 de junio
Anoche estuvimos hasta la siete de la mañana cubriendo con tablas y enmoquetando el espacio que algún día ocupará el despacho de la planta, aunque el edificio no es aún más que una maraña de vigas de todos los tamaños y algunas paredes que habrá que tirar más tarde están en el sitio equivocado. Hemos traído baterías para los fluorescentes y unos muebles de caoba preciosos. Por suerte, todo estuvo a punto para la demo. Izamos al cliente con la grúa hasta su futuro despacho y pudo contemplar la vista que disfrutaría desde el emplazamiento. El viento hizo que la pared oeste, que dos de mis compañeros sujetaban con la espalda, se derrumbara con gran estruendo sobre la mesa de caoba en el peor momento. Gracias a Dios, el cliente fue comprensivo: esto pasa siempre en las demos, y él está curado de espanto, dijo mientras el sacudíamos el polvo del traje. Dice que el lunes que viene vendrá a probar las instalaciones sanitarias. Supliremos con cubos la inexistencia de tuberías.

5 de marzo
Han transcurrido casi catorce meses. Llevamos ya siete de retraso y el edificio no acaba de superar el estado de “casi terminado”. Soy de los pocos albañiles que no ha cambiado de obra en este tiempo. Matías está consumido por la zozobra y se pasa el día en la cafetería trasegando Soberanos. El arquitecto no ha vuelto a pasar por aquí. Los rumores dicen que existieron unos planos, pero no eran de un bloque de pisos, sino de un polideportivo. Por lo visto, en las reuniones del comité de construcción se dijo que la filosofía era la misma y que sólo harían falta modificaciones mínimas. Ahora comprendo por qué nos hicieron instalar aros de baloncesto en el hueco del ascensor. Siempre dije que acabaríamos teniendo que quitarlos o aquello no era un hueco de ascensor, que era cuestión de lógica. Matías siempre me contestaba que no le viniera con tecnicismos. Estoy perdiendo la vocación de constructor. He decidido apuntarme por las tardes a un curso de informática, a ver si puedo cambiar de vida. Este oficio mío no es serio.

No related posts.

Hace algunos años ya me topé con el libro “Pragmatic Programmer”  de Andrew Hunt y David Thomas. Aconsejo a todos los que tengan la oportunidad que adquieran el libro y le den una buena leída. Muestra de manera clara muchas verdades que conocemos, pero que realmente pocas veces aplicamos. Algún día escribiré un post del libro. Pero hoy quiero enfocarme en el DRY Principle. A este principio se le conoce también como “single point of thruth” o “punto único de verdad”.

El principio establece que, en un entorno informático, la información no debe repetirse. Es decir, el conocimiento almacenado en un programa informático debe mantenerse en un, y sólo en un, lugar. De primas a primeras, el principio parece evidente, pero cuando investigamos algunas piezas de código, incluso las nuestras, nos damos cuenta que constantemente violamos el principio.

Para aclarar el concepto vamos con un ejemplo, harto común, con el que nos topamos constantemente. Supongamos que estamos haciendo una parte de un sistema en el cual se almacenará un catálogo de productos, digamos de frutas. Normalmente lo que haríamos es primero crear la base de datos. En la base de datos se tendrían estos campos: id, código, nombre, precio. En la misma base de datos agregamos ciertas restricciones al producto: el código es único y es una cadena de 10 caracteres, el nombre no puede ir vacío, el precio no pueden ser cero (observemos que incluso los tipos de esos datos radican en la creación de la tabla en la base de datos).

Una vez creada la base de datos, nos dirigimos a nuestro IDE para crear el código que trabajará con esos datos. Los enfoques varían mucho, y las maneras de trabajar con esos datos también. Pero en este caso vamos a trabajar con una capa de persistencia basada en un ORM (Object-Ralational Mapping). En algún lado de la configuración del ORM estableceremos que la tabla fruta se mapeará al objeto Fruta. Que el objeto Fruta tendrá un id, un nombre, un código y un precio.

Con nuestro mapeo funcionando, nos dirigimos a crear nuestro objeto Fruta. Nuestro objeto tendrá un BigInt para el id, tendrá un String para el código, otro para el nombre y un BigDecimal para el precio. Ahora crearemos los métodos de accesos (accessor methods) con su set y su get. Si la capa de persistencia nos echa una mano no tendremos que verificar que el código sea único, pero si no, tendremos que codificarlo nosotros.

Ahora, si somos queremos que nuestro código sea escalable y pueda mantenerse a largo plazo, utilizaremos alguna implementación del patrón MVC (Model-View-Controller, o Modelo-Vista-Controlador). En cada uno pondremos los respectivos campos de la fruta: el id, el código, el nombre y el precio. Haremos un listado de las frutas que hay almacenadas, y una forma para agregar y/o editar entradas.  En la vista le diremos al controlador qué desplegar, y haremos una tabla en el View. El model ya lo implementamos, que es nuestro objeto Fruta. Para la forma haremos lo mismo, pondremos los campos de fruta y lo guardaremos. Para proteger nuestro modelo haremos algunas validaciones del lado del servidor, pero para darle una experiencia interactiva al usuario, también haremos validaciones en el lado del cliente. Usaremos, claro está, uno de esos bonitos frameworks que ahora nos hacen la vida más fácil con javascript. La validación del código único requerirá una llamada de Ajax, y las demás serán simples validaciones con Javascript.

Ahora estamos a punto con el manejo de frutas en el sistema. Tenemos un diseño robusto, altamente escalable, muy legible. Pasamos nuestro trabajo orgullosos a control de calidad. Control de calidad nos informa que el máximo de caracteres de código es 10 y en el javascript del cliente nosotros pusimos 10. Bueno, un teclazo de más a cualquiera le pasa, ¿no?. Pasado un tiempo nos dicen que en el mapeo del ORM no pusimos correctamente el precio, y permitimos que sea vacío. Cosas, la prisa hizo que se nos pasara por alto. Pero pasado todo eso, todo bien.
Pasados unos días, nos mandan un requerimiento del cliente que pide que el código en vez de ser de 10 caracteres va a ser de 15 (cambiaron un par de cosas del negocio), y que hará falta otro código: el código de bodega que será de 20 caracteres y también hará falta el peso unitario, que será un decimal opcional.
En nuestra mente comienza a correr el tedioso proceso que tenemos que realizar: hacer los cambios en la base de datos, hacer los cambios en el mapeo, hacer los cambios en el objeto fruta, hacer los cambios en el controller y en el view para la lista, hacer los cambios en el controller y en el view (que incluye dos validaciones de javascript). Que tedio no????? Además….qué fácil será confundirnos.

A todo esto la documentación estaba ya lista, y habrá que cambiarla, pero por falta de tiempo creemos que se quedará tal y como está.

He aquí lo que nos pasa cuando violamos el principio DRY. El principio DRY establece que la información, o el conocimiento debe estar almacenado en UN SOLO LUGAR, para evitar el tedio de cambiar las cosas en mil lados cuando hacen falta cambios, además de ahorrarnos la tendencia a cometer errores cuando hay que cambiar muchas cosas que significan lo mismo. Analicemos los cambios: agregar un campo y modificar otro. Este conocimiento, en gran parte está almacenado en la base de datos (aunque no todo, por ejemplo en la base de datos no podemos hacer ciertas validaciones para los códigos, o cosas parecidas).

Por eso ideas como las aplicadas por ruby (convención sobre configuración) han sido muy populares últimamente. Grails ofrece también un enfoque bonito. Por ejemplo, si cambio las restricciones en mi setter de fruta, ¿no sería menester que esas restriccinoes se extendieran a todos lados? Agrego un campo en mi clase, agrego pesoUnitario, ¿no se deberían propagar estos cambios a la base de datos, a los controllers, a los views, al javascript, a la documentación? Por ello también soy un fan de la generación de código: permite reducir la redundancia de la información.

Nadie negará la utilidad de patrones como el MVC, o de ideas como el ORM. Pero a veces esas soluciones crean una sobre ingeniería tan grande que no sé si compensan sus soluciones. En nuestros tiempos donde los IDEs son tan poderosos nos deberían ayudar un poco más en este tema. No hablo de herramientas CASE, hablo de un nuevo enfoque de programación. Esperemos en el futuro surjan ideas y solucinoes nuevas (en las que espero ustedes y yo aportemos nuestra parte) para este problema de la constante violación del DRY. Programar debe simplificarse mucho. Hemos desarrollado soluciones a soluciones y cada año hay nuevas propuestas, pero siento lo mismo que hablaba una vez con alguien: estamos haciendo el mango del hacha más bonito, más durable, más ergonómico, más resistente a golpes…cuando lo que deberíamos estar haciendo es diseñando una sierra eléctrica!

No related posts.

Calidad en el software.

El término calidad siempre me ha parecido ambiguo. ¿Que hace que un bien o servicio “posea” calidad? No sé. Hay procesos de calidad, chequeos de calidad, y mil cosas con calidad, pero nadie entiende a ciencia cierta qué es calidad, aunque todos comprenden el término. Aunque para algunos es aquel software que no tiene bugs, para otros el que satisface al cliente, para otros es el que optimiza recursos, para otros el que se mira bonito, etc.

Cuando el término entra al contexto del software, la cosa se pone peor. ¿Qué hace que un software sea uno de calidad o no? Claro, debido a lo ambiguo del término, la discusión en este tema no tendrá fin.

Con todo, lo que hacemos es software, y nos gustaría hacer siempre software de calidad. Para poder etiquetar a un software como uno de calidad, debemos definir algunos atributos para poder poner el software en evaluación. Estos atributos, y sus prioridades, cambian cuando cambia el contexto de software: un sistema para hospitales se juzga de una manera distinta a una página web.

En FFSE R. Glass propone siete atributos del software que le confieren lo que llamamos calidad:
+Portabilidad: la portabilidad implica que un programa puede correr en distintas plataformas, no sólo de sistemas operativos sino diferentes versiones, diferentes ambientes y esquemas.
+Fiabilidad o confiabilidad: el software hace lo que debería hacer, y no “truena”.
+Eficiencia: que tanto recursos economiza en tiempo y espacio el software.
+Facilidad de uso: es fácil de usar?
+Evaluable: Es sencillo de examinar? Se le pueden correr fácilmente unit tests?
+Leíble: Es el código expresivo y fácil de comprender?
+Mofificable: Qué tan sencillo es modificar el software.
+Escalibilidad: pueden agregarse funciones de manera rápida y consistente?

Buscando en internet, encontré otros atributos que vale la pena mencionar:

+Compatibilidad: es el software amigable con otros sistemas?
+Seguridad: es el software seguro contra ataques externos?

Todos concordarán que los atributos anteriores son buenos parámetros para medir la calidad de un producto de software. Sin embargo el orden de estos productos varían de proyecto a proyecto. Un proyecto que maneja información confidencial puede que tenga la seguridad muy alta, una página de internet tendrá muy alta la facilidad de uso, un software bancario tomará más en cuenta la fiabilidad que la portabilidad.

El usuario y el código

Al usuario final le viene del norte en qué tecnología corre un programa, o que metodología de desarrollo se utilizó para su creación. Poco le importa si se utilizó un lenguaje de cuarta generación o assembler. El usuario toma por sentado ciertos estándares y cierta funcionalidad. Por ejemplo un usuario espera siempre que en el lugar que aparezca un disquete se grabe su trabajo. Si esto no funciona bien, el usuario tendrá una muy mala percepción del software, y por tanto el software no tendrá mucha calidad.

El otro lado de la moneda es la calidad del código. ¿Es sencillo de encontrar errores? ¿Hay un buen uso del modelo de programación? ¿Se optimiza el uso del hardware? Aquí cada quien tiene un criterio diferente, hay filosofías, metodologías, paradigmas y demás.

Glass expone algo que me llamó mucho la atención: la satisfacción del cliente no es lo mismo que calidad de software. Entre los elementos que evalúa el cliente están cosas como el precio del producto, el diseño, el tiempo de entrega, el soporte y otros. Un mal software puede tener una alta satisfacción (aunque poco probable), y un buen software puede ser mal valuado por el usuario (créanme, sucede). Entonces la política de calidad de la empresa en general es distinta a la política de calidad del software en sí. Pese a muchas opiniones, el software es el código y nada más. Otras cosas le van unidas, pero no son software.

En Pragmatic Programme Hunt y Thomas exponen un punto importante: software lo suficientemente bueno. En ocasiones, especialmente cuando no hay restricciones de calendario, el desarrollador quiere siempre mejorar su software. Irónicamemte un software puede ser siempre mejorado. Hay que aprender cuando un software es lo suficientemnete bueno, porque agregarle funcionalidad o mejoras puede ser hasta contraproducente si no se sabe donde parar. Al final esto es ingeniería de software, y como todas las ingenierías nuestro objetivo es calcular. Si voy a comprar alambre para cercas las plantas de mi casa puedo calcular la circunferencia usando 3 en vez de pi, si voy calcular los materiales necesarios para un edificio redondo seguramente usaré 3.14159 o tal vez más dígitos, y si estoy calculando la órbita de una nave espacial definitivamente usaré más decimales. Hay que saber cual me conviene más. Lo mismo en el software.

Existe un ISO, el 9126 que se dedica a la calidad de software tiene puntos muy interesantes. Especialmente me gustó la división que hacen para medir la calidad: la calidad del modelo, la calidad de la métrica externa, la de la métrica interna y la calidad en el uso de las métricas. Está también CMMI que se dedica a la calidad estandarizar la calidad del software y la calidad del proceso productivo de éste.

En fin la calidad de software es algo que radica entre lo objetivo y lo subjetivo. Hay mucha leña por ahí para partir, porque el universo del software es también dinámico y los parámetros también cambian. Cada equipo de trabajo tiene sus propios parámetros. Lo que quiero recalcar es que cada equipo debe definir cuales son sus parámetros para medir la calidad de su software. Luego modelar, diseñar, implementar y mantener el software apegado a esos claves. En cada proyecto el orden de prioridades cambian también y hay que tenerlo presente, porque al final de los cantares lo que queremos es que nuestro software funcione, le guste al usuario y se acerque lo más ppsible a hacer lo que tiene que hacer.

Luis H. Fernandez
luishernan@gmail.com

Algunos links.

http://synergix.wordpress.com/2008/07/02/modelo-de-calidad-tradicional-del-software/

http://blog.xebia.com/2008/11/05/what-exactly-is-software-quality/

http://en.wikipedia.org/wiki/Software_quality

http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.PDF

http://en.wikipedia.org/wiki/ISO_9126

http://www.bth.se/tek/besq.nsf/(WebFiles)/CF1C3230DB425EDCC125706900317C44/$FILE/chapter_1.pdf

No related posts.

No sólo en el software, sino que en muchas áreas, el inglés ha sido una lengua que ha metido sus narices en todas las culturas. En la nuestra con especial fuerza: programamos en inglés. Al menos yo, no conozco un lenguaje de programación cuyas palabras clave estén escritas en otro idioma. Tiene sus ventajas el uso del inglés: es más corto. Pero sobro todo tiene la ventaja de que todos podemos ponernos de acuerdo en un idioma para comunicarnos.

Y no sólo las palabras claves se escriben en inglés. Los foros, las comunidades se construyen en inglés. Las documentaciones y los bugs, todo se hace en inglés. Cuando nos topamos con algún problema extraño, llegaremos con foros en los que muchas veces ninguno de los participantes habla inglés como lengua materna, pero todos hablan inglés para intercomunicarse. Me causa gracia cuando en un foro me comunico con personas de Irlanda, India, Brasil, Rumania, México, Alemania, Rusia y etc. Me asobmra que todos nos podamos comunicar. De no existir el inglés simplemente no habría un medio de comunicación. Cuando busco un software nuevo, o alguna herramienta por ahí, espero que la página esté en inglés. Incluso cuando la página tiene una versión española, prefiero batirme con la que está escrita en la lengua de shakespeare. Sin duda el inglés permite la existencia y el crecimiento de una comunidad muy grande de desarrolladores.

Pero hablar español nos cuesta plata. Hacer programas en español nos cuesta más plata y tiempo que hacerlos en inglés. Usar ñ,á,é,í,ó,ú,ü,¿,¡ y alguno que otro por ahí es sumamente caro. Nuestro idioma tiene poco o ninguna influencia en el mundo del software. Tanto así que la misma palabra “software” la tuvimos que traer del inglés tal y como estaba. Sí, el inglés nos ayuda a aprender, pero nuestras aplicaciones las escribimos en español. Y eso no siempre es tan sencillo como parece.  Muchos de los que leen estas letras sin duda han tenido más de alguna rabieta cuando ven que en su software aparecen í,á�,é,à y otro buen montón de simbolitos raros. O cuando uno tiene que hacer maravillas para hacer que funcione una base de datos con encoding latin-1, un server con ISO-8859-1 y una aplicación con UTF-8. Alguien, con un toque de sátira, dijo una vez “lo bueno de los estándares es que hay muchos”. Más de alguno se ha puesto a llorar cuando hace un pequeño cambio y ve que cambia al charset que. Todos estamos acostumbrados a términos de charset, asdfasd, asdfasd.

En lo personal intento tratar de usar siempre UTF8, pero no siempre es posible debido a que en ocasiones no tengo el control sobre la plataforma en la que instalaré. Este es el primer post sobre el español y el inglés que haré. Hay muchos libros y muchos lugares en los que se puede obtener información sobre como hacer mejor software, pero esos siempre son en inglés (ironías), así que pienso comenzar la discusión para aquellos que hablamos español….¿cómo podemos mejorar el software en español? Lo gracioso es que siempre estaremos escribiendo aplicaciones en español definiéndolas en inglés.

No related posts.

Abro este espacio para lograr un poco de discusión y para exponer mis ideas sobre el desarrollo de software. Si estás leyendo estas letras es porque te gusta programar, porque de otra manera no te interesa mucho lo que diré.

Creo que el desarrollo de software sufre un estancamiento severo. Hemos desarrollado nuevas e interesantes técnicas, modelos de manejo de datos, metodologías de desarrollo, y un sin fin de formas para hacer las cosas. La nuestra es una tarea altamente intelectual y hemos estado viendo como hacernos la vida más sencilla.

Sin embargo los tiempos y costos de desarrollo permanecen iguales, sino es que han crecido más. El estallido de GUIs con mucho entorno gráfico han añadido dificultad a nuestra tarea. El desarrollo en web se ha tornado altamente dominante, y los usuarios esperan webs bonitas, pero a nosotros, por lo general, no nos gusta hacer cosas bonitas, nos gusta hacer cosas que funcionen. Han aparecido los diseñadores gráficos, cosa que no es mala en sí, pero no han aparecido formas de lograr una simbiosis entre programadores y diseñadores gráficos.

Todos aprendemos nuevas tecnologías y frameworks constantemente. Aparecen, y queremos usarlos. Algunas de estas ideas fructifican y se convierten en estándares de facto. Muchas otras crean un gran alboroto pero terminan quedando en lo que algunos llaman shelfware, es decir en la librera guardados y considerados como ideas interesantes pero que no aplican.

Finalmente, creo que el software es una gran oportunidad de desarrollo para Latinoamérica. La inversión en software es relativamente pequeña: una computadora y alguien que sepa usarla. No se precisan de multimilonarias fábricas ni materias primas. Necesitamos personas educadas que sepan manejar y crear y software. Siempre me he preguntado: ¿por qué de los miles de frameworks que aparecen, hay tan pocos latinoamericanos? Y cuando de casualidad me encuentro con uno de origen latinoamericano, generalmente es brasileño. Este blog tambien quiero que sea una invitación, que lance una espinita, para que desarrolladores hispanos nos pongamos las pilas y creemos. Tenemos la capacidad, aunque nos hemos dormido.

Así que bienvenidos, ojalá aparezca pronto la crítica y las ideas. El nuestro es un mundo precioso, así que démosle un toque con ñ.

No related posts.