Creo que es una de las peores maldiciones del programador, además todos te lo repiten, “antes de desarrollar hay que hacer el diseño, planeación y pre-documentación.”

Y hasta cierto punto es idiota, pues ponerse a dibujar monitos que representan al usuario, de ninguna manera me ayudan a visualizar mejor mi aplicación, cuatro palos y una bola no te hacen un buen programador.

Además para que??, si uno es bien fregón, de una sentado puede sacar el sistema. Si alguien se sintió identificado, felicidades, es un orgulloso programador, la parte no tan “felicitativa” es que entonces jamás haz tenido que desarrollar un sistema lo suficientemente grande para necesitar documentaciones.

La documentación es como las mujeres, un mal necesario, del cual siempre nos quejamos cuando somos jóvenes e inexpertos, pero al pasar los años nos damos cuenta que no podemos escapar de ellas y terminamos aceptándolas … aunque nunca nos terminen de convencer.

De esto me convenzo cada vez que necesito hacer un sistema y lo empiezo a programar en “caliente”, y a los cinco minutos tengo que estar cambiando la arquitectura porque no soportaba alguna funcionalidad, o el día de la presentación del sistema recuerdo que hay funcionalidades que se me escaparon incluir, y al final queda todo “hackish” el código.

Después de cosas así uno ya nunca vuelve a dormir a gusto, siempre pensando, “cuando se darán cuenta que su sistema esta hecho con las patas???” (jeje bueno eso nunca pasa… ni que se den cuenta, ni que uno deje de dormir).

Ahora, en mi muy humilde opinión, en la mayoría de los casos, aplicar una metodología completa es una verdadera tontera, por el simple hecho que metodologías como RUP o PMI, están diseñadas para intentar considerar todos los escenarios del desarrollo de software, de lo cual un proyecto promedio no cumple ni la mitad de las características; además insisto, dibujar monitos que apuntan a globos que dicen “ALTAS, BAJAS Y CAMBIOS DE USUARIOS” de ninguna manera me ayudan a visualizar los errores en la arquitectura que estoy planteando.

Por esto creo fervientemente que uno debe de desarrollar su propio estilo de diseñar y planear (claro, semi-basado en alguna metodología probada), en lo personal este proceso se realiza mientras voy al baño, no tengo nada mejor que hacer o simplemente la entrega es para el día siguiente; tomo una hoja blanca y empiezo a imaginar que debe de hacer el sistema, voy haciendo una prueba de escritorio mental, después pienso que voy a necesitar para esa funcionalidad, como se dividirán las funcionalidades por módulos o unidades de software y como estas van a interactuar; extrañamente mientras esto pasa, bolitas con patas pasan corriendo de un lado a otro por mi mente hablando entre ellas (tal vez si sirve eso de dibujar bolas con patas para visualizar los sistemas). Obviamente este proceso tiene que repasarse un par de veces para no olvidar especificaciones o requerimientos, pero definitivamente no incluye realizar miles de hojas de requerimientos con índice, portada, abstracto, fuentes bibliográficas y demás.

Mi punto es que, no es necesario el formalismo excesivo, se trata más de encontrar tu propia forma de planear y visualizar los problemas y su solución, no dudo que las mejores ideas del mundo estén plasmadas en pedazos de periódicos, servilletas o papel de baño… sin comentarios.

Y si alguien intenta de criticar tu forma de desarrollar software argumentando que es arcaica, carente de orden e ineficiente, siempre puedes ceñir el entrecejo y responder de manera pragmática, “No seas inocente, jamás hay que caer en parálisis por análisis”… puede funcionar ;)

Juan Carlos Olguín B