Ensaye antes de elegir

Crear una aplicación implica que se han de tomar muchas decisiones.

Algunas de ellas involucran la elección de algún framework o librería, mientras que otras giran en torno al uso de patrones de diseño concretos. En cualquier caso la responsabilidad de la decisión generalmente se encuentra en el arquitecto con el equipo. A grandes rasgos este puede reunir toda la información que puede ser juntada, luego reflexiona en base a esta durante un tiempo, eligiendo finalmente la solución desde su torre de marfil para que finalmente los desarrolladores la implementen.

Naturalmente existe una mejor manera de hacerlo.

En apoyo de su trabajo Mary y Tom Poppendieck describen una técnica para tomar decisiones.

Ellos argumentan que deberíamos retrasar el compromiso hasta el último momento de responsabilidad, este es el momento en el cual, si el equipo no toma una decisión, se la toma por ellos; o cuando la inacción da lugar a resultados que no sean (fácilmente) reversibles.

Esto es lo más prudente porque la decisión tardía estaría hecha con la mayor cantidad posible información, sobre la cual se tomará/basará la decisión.
Sin embargo, en muchos de los casos, mucha información no significa que sea suficiente información, y normalmente sabemos que las mejores decisiones se realizan a posteriori. Que significa esto para un buen arquitecto?

Un arquitecto debería mirar siempre desde fuera las decisiones que tiene que tomar pronto. El equipo es algo más que un puñado de programadores que realiza código propietario; cuando se aproxime la fecha de tomar decisiones, el arquitecto puede pedir a los desarrolladores encontrar una solución al problema durante un periodo de tiempo. Cuando llegue el momento final el equipo debe reunirse para evaluar los beneficios y desventajas de las diferentes soluciones.

Normalmente, ahora con los beneficios de la experiencia, la mejor solución para el problema es evidente para todos.

El arquitecto no tiene que tomar la decisión, él o ella simplemente dirige el proceso de toma de decisiones.

Este enfoque funciona tanto para las pequeñas, como para las grandes decisiones. También permite al equipo entender si usar o no las plantillas de Hibernate que proporciona Spring, pero este igualmente puede responder a la pregunta de que framework JavaScript debemos usar.

La duración para cada enfoque diferente, depende, obviamente de la complejidad de la decisión.

Probar dos o más enfoques al mismo problema requiere más esfuerzo que tomar primero una decisión e implementarla (aparentemente). Sin embargo, los cambios hacen que las decisiones tomadas por adelantado para una solución sean reconocidas como ineficientes (poco optimas), llevando así al arquitecto a un dilema: o bien desecha el trabajo actual o vive con las consecuencias, ambos tienen como resultado un derroche de esfuerzo. Incluso puede ser peor, ya que es posible que nadie del equipo reconozca que el enfoque elegido no fue el mejor, ya que no se analizaron más alternativas. En este caso el esfuerzo se pierde sin ninguna ocasión de reciclarlo.

Después de todo, probar múltiples alternativas o enfoques puede ser la opción menos costosa.

Erik Doernenburg

Versión original en : Try before choosing


- FIN -