Modificando aplicaciones

Hace ya algo de tiempo, en un tweet, echaba pestes por el trabajo que me estaba costando modificar el programa hecho por otra persona. Se trataba de un programa en el que valores de rutas y archivos estaban codificados en lugar de haber sido manejados como parámetros o variables. Un rato después me recordaba a mi mismo que ésta no era ni la primera vez ni el primer trabajo en el que me pasaba esto, y comencé a seguir una cadena de recuerdos sobre el asunto.

Relojes

Uno de los recuerdos, fue de un comunicado interno de mi empleador en aquel entonces, el que uno de los CE-algo remarcaba la importancia que las operaciones y tecnología tienen para la organización. El comunicado mencionaba que casi un tercio de ésta se encontraba dedicada a este rubro y que, para ser una compañía de índole financiera, las actividades y productos de las áreas tecnológicas superaban, en algunos casos, a las de compañías cuyo core business era el desarrollo de software. A pesar de tales afirmaciones, al menos en lo que corresponde a la parte de esta organización que opera en México, hay algo torcido y ha estado así desde hace ya mucho tiempo. De hecho, continua así o se encuentra peor, por lo que amigois y conocidos que laboran ahí aún o mantienen relaciones profesionales con esta empresa me han comentado. Ya he escrito sobre ello en varias ocasiones y tampoco creo que sea privativo de esta empresa. Es algo cultural.

La preocupación parecieran ser los procesos, su registro,  y no lo que se obtiene a través de éstos. Si se habla de calidad es sobre la limpieza del proceso y su cumplimiento. Si se habla de fallas lo importante es su reducción y mantener los tableros en verde (nuevamente el proceso). Si hay una auditoría, lo que se revisa (y por lo que se teme) es por cómo se ha llevado la administración de controles, documentos, registros, catálogos e inventarios, una vez más los procesos. Y suena bien todo esto pero, nadie parece preocuparse que si el producto de esto fue un elemento de software, cómo es que fue elaborado, funciona, se integra y las posibilidades de ser mantenido. ¿No debería ser esto lo más importante?

En los círculos directivos de esta organización se habla mucho de objetos, componentes, reusabilidad, reingeniería, SaaS y demás buzzwords de moda. En cuanto uno de estos términos comienza a sonar, rápidamente es adoptado y usado despiadadamente. Sin embargo nadie pregunta si se está haciendo uso adecuado de los recursos del computador, de la infraestructura de comunicaciones, de lo periféricos o por la forma en la que se está llevando a cabo el desarrollo de aplicaciones: ¿son las líneas necesarias? ¿El performance es el adecuado? ¿Se programó haciendo uso de expresiones regulares o se trata de una codificación tradicional por la piedritas? ¿Se usan arreglos o se está haciendo uso de estructuras de datos que permitan el crecimiento y adaptación de la aplicación a su entorno y cambios? Esto nunca se pregunta, tampoco se revisa, mucho menos se premia. La suposición (o esperanza quizás) es que esto sea consecuencia del proceso, y el seguimiento al proceso es lo que mi exempleador premiaba.

Desafortunadamente el proceso no puede ser resultado de un buen desarrollo o codificación, un proceso administrativo no asegurará una programación eficiente y de vanguardia. Son dimensiones diferentes. Es decisión del administrador u organización el determinar si a uno de ellos le da más peso o si los considera igualmente importantes. Los administradores favorecerán los procesos, los analistas el diseño y desarrolladores la codificación pero ninguno de estos personajes podrá hacer que toso esté bien si cada uno con cumple su parte cabalmente. La experiencia dice que forzosamente alguno se inclinará por una de ellas descuidando la otra.

Hace siglos, las comunidades feudales tenían la tradición de recorrer a pie los límites de sus propiedades con el propósito de que el conocimiento de los límite de la propiedad se perpetrara pasándose de padre al hijo al hacer estos recorridos. La topografía y agrimensura han ya abolido la práctica. A parecería efectivamente medieval si alguien recurriera a este tipo de prácticas, ¿o no? En nuestra época la administración de aplicaciones e infraestructura de cómputo tiene estas pintas. Metodologías y prácticas   se han desarrollado y tratan de aplicarse para que el código de una aplicación sea legible y se mantenga documentación de ésta. ¿Quién puede decir que esto efectivamente ocurre? Modificar código continua siendo tratar de “leer la mente” de otra persona, al grado que muchos prefieren rehacer la aplicación que modificarla (además de evitar los efectos secundarios indeseados, léase bugs), la documentación es inexistente o inútil (provee poco detalle o está desactualizada). Adicionalmente, todo programador se queda “casado” con sus desarrollos hasta que cambia de trabajo o función, en un periodo en el que “recorre a pie” el código y procesos a fin de transmitir el conocimiento a quién se le heredará la aplicación, algo que él mismo experimentará seguramente al nuevo lugar al que se dirija.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s