La Cara Oscura
del Desarrollo de Software

Está mañana recibí una llamada de lo más curiosa, un cliente (técnico) me explicaba como estaban enfocando el modelaje de un problema, y quería saber mi opinión sobre algunos aspectos del proceso de modelaje en los que él y su equipo no estaban claros.

Realmente a mí la cuestión me agarró de sorpresa, porque generalmente cuando un cliente llama fuera de la “ventana de desarrollo” de un proyecto significa que hay algún problema. Y la experiencia me dicta que los problemas siempre son “raros”, ya que los problemas “normales” los atajamos muy temprano.

Total que la llamada me pareció de lo más interesante y me hizo recordar la época en que yo andaba pendiente de si estaba al día con la última versión de UML, y para que lenguajes se podía generar el código a partir de los diagramas y demás yerbas en ese estilo.

Hoy en día, si bien aprecio enormemente la existencia del estándar y la forma en que calza en los procesos de desarrollo de software, estoy claro en que es una herramienta. Una herramienta que nos ayuda a comunicarnos con las diferentes personas involucradas en el proyecto, no un fin en sí mismo.

A algunos pocos clientes todavía les gusta pagar por diagramas, esquemas y tomos y tomos de cuidadosas descripciones, inclusive algunos insisten en imprimir la cuestión en detrimento del equilibrio ecológico del planeta.

Cuando vayan a modelar algo, a cargarlo en una herramienta que seguro tiene las letras “UML” en alguna parte del nombre, recuerden hacerse algunas preguntas:

• ¿Me ayuda esto a que haya un mejor entendimiento del dominio del problema y de la solución planteada?
• ¿Quién va a darle mantenimiento a toda esta información?
• ¿Es necesario darle mantenimiento o se muere “en el camino”?
• ¿Cómo encajan estos nuevos artefactos en mis ciclos de desarrollo?
• ¿En realidad quiero generar todo ese código?
• ¿Qué cenaré esta noche?

O como dice la gente del Agile Modeling: Model With A Purpose y Apply The Right Artifact(s).