Hoy, mientras ojeaba un rato mi facebook a la espera de un correo, me encontré con una caricatura que me dejó pensando lo suficiente sobre la necesidad de, no solamente crear software "de calidad" sino de tener procesos de calidad. Sé que al pensar en ese término se nos viene solamente una cosa a la cabeza: ¡más documentos! ¡más cosas por llenar! y si... contra la documentación exahustiva de lo que codificamos no podemos hacer nada, pero si le damos verdadero sentido entenderemos el por qué es importante.
La caricatura de la que hablaba, explicaba a grosso modo cómo serían las cosas si los edificios los construyeran los ingenieros de sistemas. Aunque el usuario nunca pudo explicarle bien al ingeniero qué es lo que quería, se plasmaba algo que siempre se ha padecido en sistemas: preguntarle al cliente qué quiere y este no sabe realmente qué necesita. Aunque esta es harina de otro costal, lo que más enfatizaba la caricatura era la necesidad de que el cliente entregara cierta documentación sobre lo que se necesita, y es a partir de esta que nace el resto de documentación con la que solemos quebrarnos la cabeza.
El por qué hay que documentar los requerimientos es claro: el cliente cambia de parecer cada que suda, y si no codificamos sobre una línea base, nuestro proyecto será eterno y complejo, pues los clientes siempre querrán agregar nuevas cosas al mismo costo ("¿Qué tanto es poner un botón adicional que llene un campito?") y si no está escrito, es muy probable que vayamos olvidando ciertas cosas.
El prototipo, los diagramas de secuencia, los diagramas de clase, los casos de uso, y todo cuanto artefacto se nos ocurra que hayamos visto en la universidad son los que a nosotros, como desarrolladores, nos darán idea de lo que tendremos que codificar (lo que el cliente quiere). Es nuestra maqueta, nuestros planos, nuestro esquema. No imagino a un ingeniero civil comenzar a construir sin tener planos del lugar, o a un cirujano cortar sin haber trazado el mapa de cortes. Es trabajo de los gerentes de software y los analistas de requisitos hacerle entender al cliente la importancia de estos documentos, y que no es simplemente "tiempo" que mal usamos mientras ellos nos pagan millonadas.
En cuanto a nosotros como desarrolladores, no hay peor pesadilla que tener que hacerle mantenimiento a código ajeno. Preferimos un harakiri con cuchillo para mantequilla antes que tener que revisar el código de otra persona; ¿por qué? porque muchas veces hacemos las cosas como si fuéramos a estar siempre presentes en el proyecto, y usamos poco o nada de las buenas prácticas de nombrado de variables, codificación, etc. Una regla de oro en la programación es: Codifica pensando en que vas a ser tú quien va a hacerle mantenimiento a la aplicación, así que escribe el código como te gustaría encontrarlo. Sé que es suena a cartel de baño, pero es la realidad. Si todos codificamos con esta regla en mente, nos facilitaremos y le facilitaremos el trabajo a los que vienen detrás.
Mi invitación es hoy a dignificar nuestro trabajo y darle su verdadero valor. Integremos como parte de nuestra vida diaria todo el sistema de gestión de la calidad y ponerse un verdadero norte como desarrollador y como parte integral de la empresa. La calidad no es un concepto nuevo, o una moda, y entre más la tengamos presente, mejor será nuestro trabajo y mayor nuestra productividad. En palabras de mi papá: "No está mal en ser pegador de ladrillos, lo que está mal es no ser EL MEJOR (o al menos intentarlo)".
Hasta una próxima.
Eliana