Sin duda todos los programadores profesionales pueden escribir un programa sin diseñarlo de antemano, el diseño se hace al vuelo, mientras se programa. Esta forma de trabajo tiene algunas aparentes ventajas, como producir rápidamente el código; sin embargo, la experiencia nos dice que generalmene todos experimentamos más desventajas que ventajas, he aquí las razones:

1. La primera solución no siempre es la mejor

Sin diseño detallado por lo general tomamos la primera solución técnica que viene a la cabeza.

Si eres programador estoy seguro que más de una vez has experimentado lo siguiente:

Estás escribiendo un pieza de código, has trabajado durante varias horas en ella y… de pronto, te das cuenta (¡ches!) que hubieras podido desarrollar tu solución de otra manera, una mejor manera. Entonces te enfrentas a la decisión de reescribir tu programa o dejarlo como está, sea cual sea tu decisión ya has perdido, en el primer caso el esfuerzo inicial incurrido y en el segundo, una mejor solución (la que no harás).

Cuando inviertes en diseñar, tienes la posibilidad de pensar en las posibles diferentes maneras de plantear las soluciones para tus programas y comparar esas diferentes maneras contra algunas variables o criterios, como ejemplo: i. restricciones de plazo.  ii. experiencia que requieres para optar una solución. iii. desempeño que debe tener tu solución, iv. larguísimo etcétera.

La idea es que tengas la oportunidad de elegir una solución para tu programa que tenga alta probabilidad de ser la mejor solución en el contexto donde estás.

( Dos notas:

A. Ojo que he escrito “alta probabilidad”, porque ya sabemos que en desarrollo de software no hay balas de plata. Quiero decir que aún haciendo este análisis al diseñar puedes, luego, durante la programación, encontrarte con otra solución mejor, pero haciendo este análisis de antemano la probabilidad de enfrentarte a esa situación disminuirá.

B. Existen problemas que primero deben resolverse para luego entender cual es la mejor solución (Ejemplo clásico: “Design is a Wicked Problem”, Puente Tacoma Narrows [McConnell 2004] ) )

2. Fomenta la reutilización ordenada

Otro aspecto benéfico del diseño es que puedes pensar en la reutilización de programas ya existentes.

La reutilización de programas es una de las armas más poderosas de los programadores, pero probablemente una de la menos utilizada.

Me refiero a la reutilización sistemática, embebida en tu forma de diseñar, no a esa reutilización oportunista en la que… sin quitar los ojos de tu programa… ni tus manos del teclado… preguntas algo como… “alguien sabe de un método para validar fechas de pago” y si ese compañero tuyo, que tiene o sabe de la rutina que necesitas, está presente y te escucha te lo podrá decir, pero si por casualidad en ese momento fue al baño o a tomar café, no oirá tu pregunta, por lo que tendrás que crear, una rutina que, posiblemente, ya existe.

Esto claramente significa que, como tu proceso de diseño no incluye un análisis de lo que se puede reutilizar, ni tú, ni tu usuario, ni tu organización podrán beneficiarse con la reutilización sistemática como parte del proceso de diseño detallado. Verdaderamente triste.

3. La pesadilla del mantenimiento de software

Y el peor, el más nocivo y más largamente extendido problema del mantenimiento de software.

Como no tenemos el diseño documentado y actualizado, tenemos que “bucear” en el código fuente para descifrar el diseño y entender cómo podemos aplicar la corrección  que necesitamos hacer a ese código, según muchos, el costo del mantenimiento de un producto de software puede ser 60%-80% de su costo original.

En lo que concierne a mi experiencia uno de los mayores dispendios de la capacidad productiva de los desarrolladores se sitúa en esta p*ta tarea de entender las tripas revueltas del programa (propio o ajeno) para poder extenderlo o corregirlo.

Finalmente…
…el hecho de que podamos emplear técnicas de refactoring no debe ser una justificación para hacerlo mal con la esperanza de arreglarlo después, ese no es el espíritu del refactoring.

Si el enfoque predominante en tu entorno de trabajo es “quick and dirty” (Rápido, si sale mal no importa, lo arreglamos después) entonces todas esas ideas te resultarán extrañas, chocantes, lejanas y exóticas; aún así, te invito a que pienses (en estas cosas).

¿Qué sigue?

Una que vez que quedas convencido que será útil diseñar antes que programar, deberás resolver el cómo se hará ese diseño, pero eso es tema de otro post.

EOF