Lo importante es que funcione

Hace unos días me encontré con este post titulado "Lo importante es !!! que funcione !!!" y no puede evitar recordar platicas pasadas en donde precisamente me comentaban lo mismo, "lo importante es que funcione".

Y si, en buena medida se tiene la razón, de nada sirve una aplicación que hace uso de todas las practicas y patrones si la aplicación nunca ve la luz.

Pero también existe la otra contraparte - la mencionada en el post -, en donde nos olvidamos por completo de cualquier norma o reglas implícitas o explícitas y simplemente "tiramos" código hasta hacer que nuestro programa funcione.

Ambos extremos son malos desde cualquier punto que se les observe.

La sobre ingeniera de una aplicación, solo viene a causar complejidad excesiva en el desarrollo y mantenimiento de una aplicación, esa complejidad se multiplica cuando se busca realizar cambios o simplemente darle mantenimiento a la aplicación.

El aplicar todas las buenas practicas y patrones, perdiendo de vista el objetivo final, que es el realizar un producto funcional, en tiempo y forma; solamente lleva a que el proyecto sea cancelado en algún momento, causando mal sabor de boca a los desarrolladores, ya que el esfuerzo empleado para lograr una buena aplicación no sirvió de nada, y si se es una empresa pequeña o mediana, obviamente también se refleja en un daño económico, por la perdida del proyecto y posiblemente del cliente.

El no "disponer" del tiempo para realizar un diseño y especificar una arquitectura de nuestra solución, y simplemente "hacer que funcione", desafortunadamente es algo común en las empresas pequeñas a medianas de desarrollo de software, como también en las empresas que no son TI pero tienen sus propios departamentos de desarrollo.

Buena parte de la ideología de "no perder tiempo" en el diseño, patrones y guías, viene de la necesidad de tener el producto terminado cuanto antes, ya que eso significa que se esta en posición de poder cobrarle al cliente cuanto antes, por lo tanto cualquier situación que "retrase" el tiempo de entrega se ve como un enemigo a tener los recursos económicos a tiempo en las empresas.

En las empresas no TI, desafortunadamente en muchos de los casos gente no TI compromete tiempos de desarrollo, en base a prácticamente nada, ante esta situación, pues también se piensa en "no perder tiempo" en el desarrollo y hacer que la aplicación funcione.

El argumento más común para implementar el proceso "haz que funcione", viene de la idea que para poder implementar un diseño y una arquitectura de nuestra aplicación implica "perder tiempo", quizás evitando esta parte fundamental del desarrollo de software, si sea posible tener un entregable en tiempo, pero la pregunta es: ¿A que costo?

Si bien todo software tiene un tiempo de vida antes de volverse "legacy", siguiendo la "metodología" "haz que funcione" acelera esta situación por las siguientes razones:

• Es muy difícil entender el código, posiblemente únicamente la persona que lo desarrolló, es el que "puede" tener un entendimiento aceptable.
• Existe una mayor posibilidad de tener "bugs" extraños y difíciles de duplicar y corregir.
• El realizarle cambios al programa se vuelve cada vez mas complejo, porque no entendemos hasta que punto esos cambios van a afectar otras áreas de nuestro programa.
• No hay forma de reproducir situaciones muy particulares que ocurren con nuestro software y si este inter-actua con otro mas, lo mas común es culpar al otro software.
• Inicialmente quedamos "bien" con el cliente por entregar el software a tiempo, a la larga los errores y fallas de nuestro software nos ponen en una situación no muy buena, y si a esto le agregamos que le cobramos al cliente por arreglar nuestros "errores", pues todavía peor.

El caso es encontrar el punto medio, si como empresa de desarrollo no seguimos buenas practicas para el desarrollo de nuestras soluciones, tratar de implementarlas de un momento a otro, únicamente va a producir un desastre y volveremos a las viejas practicas al instante.

Es necesario identificar las practicas que pueden traer un beneficio mayor a nuestra organización y primeramente "evangelizar" entre nuestro grupo de desarrollo antes de siquiera intentar implementarlas, una vez que decidimos implementarlas, es importante comenzar un tanto relajados en su aplicación, una vez que el equipo se haya acostumbrado, entonces empezar a "apretar" poco a poco para que estas se cumplan.

Actualización: En el blog de Eber Irigoyen, el comenta sobre la idea de "Deuda Técnica" a este problema de únicamente hacer que funcione.

Imagén notebook MyImageCollections
Imagén diseño subWiz
Imagén de los problemas de software Ryan Coleman
Imagén Programador frustrado Sybrem A. Stuvel